moolre-mcp

Official

by moolrehq

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, especially between payments, SMS, and WhatsApp. However, there is potential ambiguity among SMS-related tools (e.g., sender_id_status vs list_sender_ids, and send_sms vs send_sms_get) which could cause confusion. Descriptions help but still could be clearer.
Naming Consistency4/5
Tool names predominantly follow a verb_noun pattern (e.g., create_account, send_sms), but a few like account_status and sender_id_status use noun_status instead of a verb. This minor inconsistency lowers the score slightly.
Tool Count4/5
With 24 tools covering payments, SMS, and WhatsApp, the count is slightly high but justified by the breadth of functionality. It remains manageable and each tool has a defined role.
Completeness3/5
Core operations are covered (create, read, update for accounts; send and check for SMS/WhatsApp), but there are notable gaps: no tool to update or delete sender IDs, no cancellation for transfers, and no listing of generated payment IDs or bank accounts. This may cause agent failures in some workflows.
Average 3.2/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description only states 'Create a new...', omitting important traits such as side effects (e.g., does it modify other resources?), required authentication, idempotency, or error conditions. This is insufficient for a creation tool.
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 very concise (single sentence), but it sacrifices completeness. For a tool with 6 parameters and no output schema, more detail would be beneficial. The brevity is positive, but the information density is low.
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 (6 parameters, nested objects, no output schema), the description is too minimal. It fails to explain the creation outcome, required headers, or how to handle responses. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented in the schema. The description adds no additional semantic value beyond the schema, but the baseline of 3 is appropriate since the schema itself is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Create' and specifies the resource 'Moolre business wallet/account', clearly indicating the action and object. It distinguishes from sibling tools like update_account or account_status. However, it could be more precise about the type of account being created.
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. There is no mention of prerequisites (e.g., authentication required via headers) or context for when this tool is appropriate. The usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. While 'instantly' hints at speed, it does not disclose whether the operation is idempotent, what happens to the sender's balance, what errors can occur, or if there are fees. The description's claim of 'instant' is vague and lacks detail about actual 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 sentence of 10 words, which is concise and front-loaded. However, it sacrifices necessary detail for brevity, leaving out critical context. Conciseness is achieved but at the cost of completeness, making it merely adequate.
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 9 parameters (6 required), nested objects (headers), and no output schema. The description covers only the high-level purpose. It omits how to specify the channel number, how headers are passed, what the externalref format should be, whether the transfer is immediate or might be delayed, and what the response looks like. Given the complexity, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 9 parameters have descriptions in the schema. The description does not add any information beyond what is already in the schema (e.g., it does not clarify the channel mapping or required credentials). Baseline 3 is appropriate as the description adds no marginal value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send money') and the target resource ('Mobile Money or Bank Account'), with the adverb 'instantly' adding temporal specificity. This is sufficient to distinguish from many sibling tools like 'internal_transfer' or 'send_sms', though it does not explicitly differentiate from 'initiate_payment' or 'transfer_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'internal_transfer' (internal account transfers) or 'initiate_payment' (possibly different payment flows). No when-not-to-use conditions or context triggers are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'permanent' and 'linked', but does not mention idempotency, auth requirements, or if previous numbers are invalidated. Lacks important safety details.
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 is concise, but lacks structure (e.g., no bullet points or separate sections). Could be more informative without being 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 9 parameters and no output schema, the description is too brief. It doesn't explain return values, how the account number is linked, or what 'wallet/account' refers to. Incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only states the tool's action, not parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses clear verb 'Generate' and resource 'virtual bank account number', and states purpose 'for secure payments'. However, 'secure payments' is somewhat vague, and it doesn't explicitly differentiate from sibling tools like 'create_account' or 'create_payment_id', but it is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as 'create_account' or 'generate_payment_link'. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'for approval' implying the payment is not immediate, but it does not explain the USSD flow, required authentication (headers), or that the payer must approve via their phone. Important aspects like idempotency or error states are omitted.
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, concise and to the point. However, it could include a bit more context without becoming verbose, such as acknowledging the approval step or the need for valid phone numbers.
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 no output schema, so the description should explain what the tool returns (e.g., a reference ID, status, or confirmation). It does not. Also, the complexity of having 10 parameters (including nested objects) is not addressed. The description is too sparse given the tool's role in payment initiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema. Each parameter is described in the schema, and the tool description does not elaborate on their usage or relationships.
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 'Send a USSD payment request to a payer's phone number for approval,' specifying the verb (send) and resource (USSD payment request). It distinguishes from sibling tools like initiate_transfer by focusing on USSD-based payment requests. However, it does not mention the mobile money context or that it applies to specific networks.
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 guidance on when to use this tool versus alternatives such as initiate_transfer or payment_status. No prerequisites or conditions are stated, and there is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the action. It does not disclose whether the transfer is immediate or scheduled, if it's reversible, or what happens to the source account. For a money movement tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous text. Front-loaded with the core purpose. 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 7 parameters including headers and nested objects, no output schema and no annotations. The description is minimal and does not explain expected outcomes, security context (headers imply auth but not explained), or what 'internal' specifically means. Incomplete for a financial transfer tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brief descriptions for each parameter. The tool description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate as the schema does the work, but no value added.
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?
Description clearly states 'Initiate an internal transfer using your Moolre account.' It specifies the action (initiate) and resource (internal transfer), but does not differentiate from sibling tools like 'initiate_transfer' or 'initiate_payment', which could be overlapping.
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. Given numerous sibling tools related to transfers and payments, the lack of context on when 'internal' applies (e.g., vs. 'initiate_transfer') leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states it returns a list. No mention of pagination, auth requirements (though headers imply it), rate limits, or response format. Does not clarify if listing is paginated or the scope of transactions included.
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 wasted words. However, it could be slightly more informative without being verbose. Front-loaded with the core function.
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 6 parameters, 1 required, nested objects, and no output schema, the description is insufficient. It doesn't explain the return structure or pagination behavior, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), so the schema already explains them. The description adds no extra meaning beyond what the schema provides, meeting the baseline.
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?
Clearly states the tool returns a list of transactions for a specific account. The verb 'list' and resource 'transactions' are specific, and it distinguishes from sibling tools like transfer_status or initiate_transfer.
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?
Provides no guidance on when to use this tool vs alternatives, such as transfer_status or payment_status. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool sends SMS requires an API key. It fails to disclose critical behaviors such as whether the operation is destructive, rate limits, idempotency, or what happens on failure.
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 with no waste, directly stating the endpoint and action. It is appropriately concise, though it could benefit from slightly more detail 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?
The tool involves nested objects, required headers, and bulk operations, which are complex. The description is too brief to cover return values, error handling, or how to properly construct requests. It leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%+), so the baseline is 3. The description adds only the requirement for X-API-VASKEY; it does not explain the meaning of 'type: 1' or the structure of 'messages' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends SMS messages (bulk or single) and identifies the resource. It distinguishes the basic action from the sibling send_sms_get (which likely retrieves messages). However, it does not explicitly differentiate from other SMS-sending tools that may exist.
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 mentions a requirement (X-API-VASKEY) but provides no guidance on when to use this tool over alternatives like send_sms_get or when not to use it. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the HTTP method (POST) and authentication requirement, but does not disclose whether the operation is read-only, side effects, rate limits, or response format. This is minimal coverage for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus endpoint) and front-loaded with the purpose. It is concise but sacrifices necessary detail. Every word has a purpose, but more information could be included without harming 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 no output schema and moderate complexity (2 params, nested object), the description is incomplete. It does not describe the response format, error handling, or additional context like rate limits. The tool's behavior is not fully specified for reliable selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what is in the input schema; it mentions 'type 2' which is already documented. No value added.
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 checks SMS credit balance ('Check SMS credit balance') and provides the HTTP endpoint. It distinguishes from sibling tools like 'account_status' and 'sms_status' by mentioning 'type 2' and the resource, though not explicitly, so it is clear.
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 mentions a prerequisite ('Requires X-API-VASKEY') but gives no guidance on when to use this tool versus alternatives like 'account_status' or 'sms_status'. No exclusion or contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions the HTTP method and required header but does not state whether the operation is read-only, has rate limits, or returns paginated results.
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 short but includes unnecessary implementation details like the full URL and 'type 7'. It is not front-loaded with the tool's 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?
Missing critical context for a listing tool: no description of response format, pagination behavior, or limits. The description covers only basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented. The description adds emphasis on 'Requires X-API-VASKEY', but adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all registered Sender IDs', which is a specific verb and resource. It distinguishes from sibling tools like create_sender_id by implying a read-only listing operation.
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 context on when to use this tool vs alternatives (e.g., create_sender_id or approve_sender_id). No explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions authentication requirement (X-API-VASKEY). Does not disclose side effects, idempotency, conflicts, or response behavior.
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?
Description is one line with endpoint info and requirement. Front-loaded but could benefit from clearer structure (e.g., bullet points for requirements). 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?
No output schema, complex nested objects, and many sibling tools. Description is too brief; does not explain return format, success/error behavior, or rate limits. Incomplete for complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%. Description adds no new meaning beyond the schema; it restates the endpoint and 'type 3' which is already in schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Request a new Sender ID) and resource. It distinguishes from sibling tools like list_sender_ids (list) and approve_sender_id (approve).
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 or when not to use this tool versus alternatives. Only prerequisite (X-API-VASKEY) is mentioned, but not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions it's a POST and requires X-API-VASKEY, but does not clarify that this is a read-only operation (despite being POST), nor does it describe error responses, rate limits, or side effects.
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 very concise with no wasted words. However, it includes the endpoint URL which is not standard for tool descriptions, but it is still efficient.
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 3 parameters, nested objects, and no output schema. The description does not explain the response structure, prerequisites (e.g., sender ID must exist), or how to interpret the result. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds that 'type' must be 1 (already in schema) and mentions requiring X-API-VASKEY (also in schema). No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check Sender ID approval status') and the resource ('Sender ID'). It distinguishes from sibling tool 'list_sender_ids' which lists all sender IDs, while this checks a specific one.
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 'create_sender_id' or 'list_sender_ids'. The description lacks context for when to call this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'check', implying read-only, but does not state whether mutations occur, rate limits, authentication failures, or other side effects.
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 is concise and direct, but could be slightly expanded with additional context without losing 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?
Given the tool has 2 parameters (including a nested object), no output schema, and no annotations, the description is adequate but minimal. It fails to describe the response format, error conditions, or authentication implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions in the schema). The description adds no further meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check a Moolre wallet's balance and status' uses a specific verb ('Check') and resource ('wallet's balance and status'), clearly distinguishing it from sibling tools like 'transfer_status' or 'sender_id_status' which check 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?
The description provides no guidance on when to use this tool versus alternatives, such as not mentioning that it only returns balance/status without filtering or pagination, and does not list excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'permanent' but does not explain side effects, idempotency, rate limits, or required authentication (though headers are in the schema). The description adds minimal behavioral context beyond the core generation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential purpose without any filler. Every word is functional, making it highly concise for the information it conveys.
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 6 parameters, no output schema, and no annotations, the description is too brief. It fails to explain the return format, how the ID is used in payments, or any dependencies (e.g., needing a valid account). The USSD context helps but leaves significant gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the input schema. The description does not add further parameter-specific meaning, such as how 'name' or 'externalref' influence the generated ID. Baseline 3 is appropriate as the schema handles the load.
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 generates a permanent payment ID and provides the USSD dial format. It is specific about the verb 'generate' and the resource 'payment ID', but does not explicitly differentiate from sibling tools like 'generate_payment_link' or 'initiate_payment', which manage payments differently.
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 hints at usage via USSD code, giving context on when to use the generated ID, but lacks explicit guidance on when not to use this tool or alternatives. There is no mention of prerequisites or exclusions, leaving the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that the tool creates a URL, but fails to mention if it modifies state, requires specific authorization, has rate limits, or what the response format is. The creation action implies mutation, but no safety details are given.
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. It conveys the essential purpose without any unnecessary words or redundancy. Every part of the sentence adds value.
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 (11 parameters, 6 required, no output schema), the description is too minimal. It does not explain the output (presumably a URL), expected inputs format, error conditions, or prerequisites like having a Moolre account. This leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any further meaning beyond what the schema already provides for each parameter. It does not explain parameter interactions or constraints, but the schema itself is sufficiently descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'hosted Moolre Web POS payment page URL', and the purpose 'collecting payments'. It uniquely identifies the tool's function among many sibling tools focused on different areas like SMS, transfers, and account management.
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 initiate_payment or create_payment_id. The description lacks context for when not to use it, prerequisites, or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it's a GET request and requires a key; it does not disclose idempotency, rate limits, error handling, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with HTTP method and URL. Efficient and concise with 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?
No output schema exists, so description should explain return values. It does not mention what the response contains (e.g., list of templates). For a fetch tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds that X-API-VASKEY is required, but the schema already describes both headers. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch WhatsApp message templates' with a specific resource URL. However, it does not differentiate from sibling tools like send_whatsapp_message or whatsapp_message_status, though those have distinct purposes.
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 mentions the required header X-API-VASKEY, providing a prerequisite. But it does not give guidance on when to use this tool versus alternatives like list_sender_ids or send_whatsapp_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Update' implying a write operation but does not disclose any behavioral traits such as idempotency, permission requirements, or side effects. The description is too minimal.
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. It covers the essential purpose without unnecessary words, but could benefit from slightly more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (6 parameters with nested objects), the description is adequate but incomplete. It does not explain return values, constraints on updates, or how settlement specifics work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds 'details and settlement settings' but does not elaborate on specific parameter meanings beyond what the schema already provides. No additional semantic value.
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 specifies the verb 'Update' and the resource 'Moolre business wallet/account's details and settlement settings'. It distinguishes this tool from siblings like 'create_account' (creation) and 'account_status' (status read).
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 when to create versus update, or any prerequisites. The description lacks context on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is a GET request to send an SMS, which is a non-idempotent, state-changing operation. This contradicts the expected safe nature of GET. No disclosure is made about side effects, success/failure behavior, or error handling. Given no annotations, the description fails to alert the agent to the mutation risk.
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 efficiently communicates the core action, endpoint, and a key requirement. It is front-loaded and concise. However, it could be slightly more structured to separate the URL from the description of operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important context: no mention of response format, success/failure indicators, or how to pass the required headers (the schema nests them as an object but GET requests pass them as HTTP headers). The size warning on the message parameter (max 160 chars) is in the schema, not the description. The description is incomplete for an agent to confidently invoke or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds only that the request uses query parameters and requires X-API-VASKEY, which is already in the schema. No additional semantic value beyond the schema is provided, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a single SMS'), the method ('GET via query parameters'), and the resource ('SMS'). It also provides the full API endpoint URL, making the purpose unambiguous. The tool is distinct from sibling 'send_sms' which likely uses POST.
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 mentions a prerequisite ('Requires X-API-VASKEY') which is helpful. However, it does not explain when to prefer this GET variant over the POST 'send_sms' sibling, nor does it specify any constraints on usage (e.g., rate limits, idempotency). The guidance is minimal.
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?
Without annotations, the description must disclose behavioral traits. It mentions it's a POST request and requires X-API-VASKEY, but does not describe rate limits, failure modes, or whether it is read-only. This leaves gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it includes the URL and type, which slightly clutters it. However, it is concise and front-loaded with the key action.
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 is provided, and the description does not mention return behavior (e.g., what status information is returned). It also lacks details on ref array size limits. The tool's context is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds context that type must be 5 and that a specific header is required, but does not explain ref's format or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks SMS delivery status by reference, using a specific verb and resource. It distinguishes from sibling tools like send_sms (which sends) and other status 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?
No explicit when-to-use or alternatives are provided. The purpose is clear, but there is no guidance on when to prefer this over other tools or whether it fits specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes the tool as a tracking operation but does not mention whether it is idempotent, rate limits, error handling, or what happens with invalid references. The response format is also omitted.
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, clear sentence (13 words) that front-loads the action. Including the HTTP method and URL is slightly unusual for MCP but does not detract 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?
Given the absence of an output schema, the description should explain the return value. It does not. It also lacks information on error handling, pagination, or response structure. For a simple tracking tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, merely restating the concept of 'by reference' which aligns with the 'ref' parameter.
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 ('Track'), the resource ('WhatsApp message delivery'), and the key qualifier ('by reference'). It distinguishes the tool from siblings like 'sms_status' and 'send_whatsapp_message'.
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 after sending a message by mentioning 'by reference'. It also notes the required header 'X-API-VASKEY'. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide conditions for not using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the auth requirement (X-API-VASKEY) and the mutation action. However, it lacks details on side effects, rate limits, or error states, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. It front-loads the HTTP method and endpoint, then immediately conveys the core purpose. Every word is necessary and no extraneous information is present.
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 nested objects and no output schema, the description is too sparse. It does not explain the return format, error handling, or the full scope of which sender IDs can be approved/rejected. Admin requirements are mentioned but not expanded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes most parameters (type, senderids) with good coverage (67%). The description adds value by specifying that type must be 6 and that X-API-VASKEY is required, which ties into the headers parameter. This additional context enhances understanding.
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 verb 'Approve or reject' and the resource 'Sender IDs', and notes it's for admin use. This distinguishes it from sibling tools like 'create_sender_id' and 'list_sender_ids'. However, the endpoint path 'sms/status' could cause confusion as it doesn't match the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for approving/rejecting sender IDs and requires admin privileges. It does not explicitly state when not to use this tool or provide alternative suggestions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool is a write operation (POST) and requires authentication, but does not disclose potential side effects, rate limits, or error scenarios. The batch nature is mentioned, which adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence plus a requirement note. It front-loades the endpoint and key function. However, it could be more structured by separating the requirement into a dedicated line or bullet.
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 (nested objects, multiple parameters) and absence of an output schema, the description fails to explain what the tool returns or how to interpret the response. Users of sibling status tools may infer the behavior, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, meaning most parameters have descriptions in the schema. The tool description adds little beyond stating 'batch' and the endpoint. No additional constraints, examples, or explanations are provided for parameters like headers or placeholders.
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 sends batch WhatsApp template messages via a specific POST endpoint. It explicitly uses 'batch' and 'template messages' which distinguishes it from sibling tools like send_sms, and the mention of the endpoint URL adds specificity.
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 mentions the requirement for 'X-API-VASKEY' but provides no explicit guidance on when to use this tool vs alternatives such as whatsapp_message_status or get_whatsapp_templates. Usage context is implied by the resource name, but no exclusions or conditions are specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only, idempotent operation but does not mention authentication requirements (though implied by the schema), rate limits, or whether the status is pollable. Lacks detail on side effects or response 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 a single, efficient sentence (9 words) that conveys the core purpose without any superfluous information. It is front-loaded and 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 the tool having no output schema and a moderately complex input (nested headers, 3 required parameters), the description fails to explain what the tool returns (e.g., status values, error handling) or how to interpret results. It leaves significant gaps for an agent to act correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the description adds no additional parameter-level context. The baseline of 3 applies as the description does not compensate for or clarify parameter nuances beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the final status of a previously initiated payment collection.' It uses a specific verb ('check') and resource ('final status of a previously initiated payment collection'), which distinguishes it from sibling tools that initiate payments or check other statuses.
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 after initiating a payment collection but provides no explicit guidance on when to use this tool versus alternatives like 'transfer_status' or when not to use it. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool performs a name confirmation (likely a read-only check), but it does not specify the return format, error handling, or whether any state changes occur.
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 (18 words) that immediately conveys the tool's purpose. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (including nested headers), no output schema, and no annotations, the description could explain expected output (e.g., the confirmed name) or potential errors. It provides basic context but leaves gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the input schema. The description adds no additional parameter-level detail beyond the schema, so it meets the baseline but does not exceed 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 uses a specific verb 'Confirm' and clearly identifies the resource (name of Mobile Money or Bank Account holder). It distinguishes the tool from siblings like initiate_transfer and list_transactions by specifying its use case as a prerequisite step before initiating a transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'before initiating a transfer,' which provides clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools, leaving a minor gap.
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?
Description indicates read-only, non-destructive behavior ('check'). No annotations to contradict. Lacks details on rate limits or prerequisites, but adequate for a simple status check.
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, no superfluous content.
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?
No output schema, but for a straightforward query with well-documented parameters, the description is sufficient. Could mention that it returns status, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('check') and resource ('final status of a previously initiated transfer'). Distinct from sibling tools like 'initiate_transfer' and 'payment_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after initiating a transfer, but no explicit when or when-not guidance, nor alternatives mentioned.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/moolrehq/moolre-mcp'

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