Provides MongoDB integration for tracking orders, storing user profiles, and managing order lifecycle states such as PENDING, CONFIRMED, IN_TRANSIT, and DELIVERED.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BulkClix MCP Server what's my wallet balance?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python-based MCP (Model Context Protocol) server that gives AI agents (LibreChat, Claude Desktop, Cursor, etc.) full access to ghanaian platforms via natural language.
Developed with FastMCP for simple tool declarations.
Food & Catalog Ordering: Search food menus across Accra/Bolt Food catalog, place merchant orders via SMS, collect MoMo payments.
MongoDB Order Tracking: Save user profiles, delivery addresses, and track live order lifecycle states (PENDING, CONFIRMED, IN_TRANSIT, DELIVERED).
SMS: Send bulk SMS, fetch campaign reports, request/list Sender IDs.
OTP: Send and verify OTPs via SMS and Email.
Airtime: List networks, purchase airtime via momo, and send airtime from wallet balance.
Mobile Money: MoMo payment collections, status checks, disbursements.
Bank Transfer: Disburse to bank accounts, list banks.
Data Bundles: Fetch bundles, purchase data packages.
KYC: MSISDN owner name lookups.
Contacts: Full CRUD for contact groups & contacts.
Account: Check wallet balance.
Related MCP server: AgentPhone MCP Server
Run the server along with the mini MongoDB instance for tracking orders and storing user profiles:
docker-compose up -dUsing uv is highly recommended as it automatically manages dependencies:
# Run server using uv
uv run server.pyIf you want the server to use a default BulkClix key, set BULKCLIX_API_KEY before starting it:
export BULKCLIX_API_KEY="your-bulkclix-api-key"
uv run server.py mcpTo expose admin-only workflows like contact management, enable internal tools on the server:
export BULKCLIX_ENABLE_INTERNAL_TOOLS=trueThe public chat-facing tools now work without caller-supplied keys. SMS and OTP tools automatically pick the first sender ID returned by BulkClix. Airtime and data purchases first collect payment through MoMo, then complete the fulfillment after payment is confirmed.
Add this under mcpServers in your librechat.yaml:
mcpServers:
ananse:
command: uv
args:
- run
- --directory
- /path/to/ananse-mcp
- server.py
type: stdioRun the server on a port (e.g. port 8000):
cd ananse-mcp
uv run server.py mcpThen configure LibreChat to use the MCP-over-HTTP endpoint:
mcpServers:
bulkclix:
url: http://localhost:8000/
type: sseYou can then tunnel that port with localtunnel:
npx localtunnel --port 8000If BULKCLIX_API_KEY is set on the machine running the server, the client can use the public tools without providing any per-call key.
Admin-only tools are hidden unless BULKCLIX_ENABLE_INTERNAL_TOOLS=true is set on the server.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0). See the LICENSE file for details.
Get supported networks for airtime top-up.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. Description adds minimal behavioral context beyond stating the tool's purpose, which is acceptable given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description sufficiently explains the tool's purpose for a simple list retrieval with no parameters and an output schema. Could be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. Schema coverage is 100% (trivially). Baseline 4 applies; description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('supported networks for airtime top-up'), clearly distinguishing it from sibling tools like airtime_purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., when to get networks vs purchase airtime). Sibling tools exist but no explicit context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an airtime purchase using the BulkClix purchase route. :param destination: Recipient phone number receiving the airtime. :param phone_number: MoMo phone number being charged for payment. :param network: Payer network code (e.g., 'MTN', 'VDF', 'ATL'). :param amount: Airtime purchase amount in GHS. :param network_id: Network UUID from airtime_get_networks. :param payment_type: Payment type (usually 'momo').
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Airtime purchase amount in GHS. | |
| network | Yes | Payer network code (e.g., 'MTN', 'VDF', 'ATL'). | |
| reference | No | ||
| network_id | Yes | Network UUID from airtime_get_networks. | |
| destination | Yes | Recipient phone number receiving the airtime. | |
| callback_url | No | ||
| payment_type | No | Payment type (usually 'momo'). | momo |
| phone_number | Yes | MoMo phone number being charged for payment. | |
| await_payment | No | ||
| transaction_id | No | ||
| timeout_seconds | No | ||
| poll_interval_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only (readOnlyHint=false) and not destructive. The description adds no behavioral details beyond what annotations provide, such as success/failure conditions or side effects like charging the phone number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a list of parameter descriptions, which is functional but verbose. It could be more concise by summarizing the tool's action and highlighting key required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and many optional parameters, the description lacks context on expected return values, asynchronous behavior, or error handling. It does not explain what happens after 'starting' the purchase.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description repeats some parameter descriptions already present. It adds minor clarifications (e.g., 'Airtime purchase amount in GHS') but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts an airtime purchase using a specific route (BulkClix). It distinguishes from sibling tools like data_purchase or airtime_get_networks by focusing on immediate purchase initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no context for expected usage scenarios. It only lists parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order with a food/goods vendor and initiate mobile money payment via BulkClix. IMPORTANT: Before calling this tool you MUST have collected ALL required fields from the user: (1) if order_type='inhouse' — you MUST ask the user for their table_number first; (2) if order_type='delivery' — you MUST ask the user for their delivery_address first. Do NOT call this tool without those values — the tool will fail. :param vendor_id: Vendor's UUID. :param items: List of items to order, with dish_id, quantity, and addon_ids. :param payment_number: Mobile money number to charge (e.g. '0544929180'). :param network: Mobile money network code (e.g. 'MTN'). :param order_type: 'inhouse' or 'delivery' — must be one of the vendor's supported order_types. :param table_number: Table number string. REQUIRED when order_type is 'inhouse' — ask the user before calling. :param delivery_address: Delivery address string. REQUIRED when order_type is 'delivery' — ask the user before calling. :returns: dict with success, order_id, payment status, and vendor confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of items to order, with dish_id, quantity, and addon_ids. | |
| network | Yes | Mobile money network code (e.g. "MTN"). | |
| vendor_id | Yes | Vendor's UUID. | |
| order_type | No | "inhouse" or "delivery" — must be one of the vendor's supported order_types. | inhouse |
| table_number | No | Table number. Required when order_type is "inhouse". | |
| payment_number | Yes | Mobile money number to charge (e.g. "0544929180"). | |
| delivery_address | No | Delivery address. Required when order_type is "delivery". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write and open-world behavior. The description adds context by explaining the payment initiation, failure conditions if prerequisites are missing, and the return value structure, which goes beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and important notes, then lists parameters. It is slightly verbose by repeating schema descriptions, but still efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, conditional requirements, payment initiation) and availability of output schema mention, the description covers purpose, prerequisites, conditional fields, and return shape. Missing details on payment failure handling are acceptable as output includes payment status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical preconditions: table_number needed for inhouse, delivery_address for delivery, and that these must be asked before calling. This semantic guidance is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places an order with a food/goods vendor and initiates mobile money payment via BulkClix. It distinguishes from siblings like get_verified_vendors (listing) and place_merchant_order (likely for non-verified or different flow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important prerequisite note about collecting required fields before calling, and conditional requirements for order_type. However, it does not explicitly compare with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a data bundle payment or purchase by order ID.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ||
| payment_id | No | ||
| transaction_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description ('Check the status') aligns with the readOnlyHint annotation, indicating a safe read operation. However, it does not add any behavioral details beyond the annotations, such as authentication requirements or rate limits. Since annotations already provide the safety profile, the description is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose without any wasted words. It is concise and to the point, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (indicated) and moderate complexity (3 params, 1 required), the description lacks completeness. It does not explain the role of optional parameters or what the status response contains beyond 'status'. Parameter coverage is minimal, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (order_id, payment_id, transaction_id) with 0% schema coverage in the description. The description only mentions 'order ID', leaving the purpose of payment_id and transaction_id unexplained. With such low coverage, the description should compensate but fails to do so adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check', the resource 'status of a data bundle payment or purchase', and the key identifier 'order ID'. It effectively distinguishes from sibling tools like 'momo_check_status' (mobile money) and 'track_order' (general orders) by specifying the data bundle context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when an order ID for a data bundle payment or purchase is available, but it does not provide explicit guidance on when to use it versus alternatives like 'momo_check_status' or 'track_order'. No when-not-to-use or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available data bundle services.
| Name | Required | Description | Default |
|---|---|---|---|
| network_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, which sufficiently indicate a safe read operation. The description adds no extra behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, very concise. However, it is too brief and omits important parameter information, making it incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional param, no nested objects, output schema exists), the description is minimally adequate but lacks parameter details. For a list tool, it could still be functional but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (network_id) with 0% schema description coverage, but the description does not mention it or explain its purpose. The description should compensate for the lack of schema docs but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available data bundle services.' clearly states the verb 'list' and the resource 'data bundle services'. It distinguishes from the sibling 'data_get_offers' which likely lists offers, but could be more specific about what defines a 'bundle'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'data_get_offers' or 'data_check_status'. The description simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available data bundle offers for a service and phone number. :param service_id: Data service UUID. :param phone_number: Recipient phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | Data service UUID. | |
| phone_number | Yes | Recipient phone number. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, destructiveHint false. Description adds no new behavioral traits beyond listing offers; it's consistent but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with param descriptions; no fluff. Could be front-loaded better, but concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple list tool with output schema present; description covers core purpose and parameters. Missing minor context like ordering or filtering, but adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and description merely repeats the param descriptions. No additional meaning beyond what schema provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'available data bundle offers', clearly distinguishing from siblings like data_get_bundles (lists bundles for purchase) and data_check_status (checks status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for viewing offers before purchase, but no explicit when-to-use or alternatives. Siblings like data_purchase are nearby, but no guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a data bundle purchase using the BulkClix purchase route.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | ||
| bundle_id | Yes | ||
| reference | No | ||
| network_id | Yes | ||
| service_id | Yes | ||
| callback_url | No | ||
| phone_number | Yes | ||
| await_payment | No | ||
| customer_name | No | ||
| transaction_id | No | ||
| timeout_seconds | No | ||
| poll_interval_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation (readOnlyHint=false) with openWorldHint=true. The description adds only the route name but fails to disclose important behavioral traits like payment initiation, async polling, or side effects. Parameters like 'await_payment' and 'timeout_seconds' suggest complex behavior, but the description is silent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly terse given the tool's complexity (12 parameters, no schema descriptions). It sacrifices clarity for brevity and does not earn its place by adding value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the tool has 12 parameters with zero description, no workflow explanation, and no mention of important concepts like the BulkClix purchase route's requirements. The description is inadequate for an agent to use this tool correctly in a realistic scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions). The tool description adds no meaning to any of the 12 parameters, leaving agents without context for fields like 'bundle_id', 'network_id', or 'await_payment'. This severely impairs correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a data bundle purchase using the BulkClix route, specifying the verb ('Start'), resource ('data bundle purchase'), and method ('BulkClix purchase route'). It distinguishes from sibling tools like data_get_bundles or data_get_offers that list bundles or offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites (e.g., need to fetch bundles first via data_get_bundles), and no exclusions. Users are left to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for food items, dishes, pizza, rice, chicken, or menus across all verified vendors or a specific vendor. Use this when asking 'what food is available', 'show me the menu', 'do you have pizza', 'search menu for burger'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| vendor_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, non-destructive behavior. Description adds only example search terms, not additional behavioral details like pagination, result limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a search tool with annotations and output schema present. Covers scope and use cases; missing details on empty results or error cases, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description hints at vendor_id usage and query examples. Doesn't specify query format or constraints, so adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for food items, dishes, pizza, rice, chicken, or menus' with specific verb and resource, and provides example queries that distinguish it from sibling tools like search_food_menus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries and mentions scope (all vendors or specific vendor via vendor_id). Lacks explicit when-not-to-use or comparison to siblings, but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a saved customer profile from MongoDB by phone number to get delivery address and payment preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| phone_number | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds little extra behavioral context. Mentioning MongoDB is minor. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence (16 words) with no wasted words. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, a clear description, and an output schema (as indicated), the description is fully adequate for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description clarifies that 'phone_number' is the key for retrieval, adding meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'retrieve', the data source 'MongoDB', the parameter 'phone number', and the output 'delivery address and payment preferences'. It clearly distinguishes from sibling tools like 'save_customer_profile' and 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing customer delivery address and payment preferences, but does not explicitly state when to use or avoid this tool, nor mention alternatives like 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns information about the Auth0 token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond what is implied by the annotations, such as token validity, authentication requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it could include slightly more detail about the type of information returned without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema, the description is minimally adequate. It does not add extra context beyond the name, but nothing critical is missing for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% schema description coverage. The description does not need to add parameter details. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns information about the Auth0 token' clearly states the verb ('Returns') and the resource ('Auth0 token'). No sibling tool has a similar purpose, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or when not to. The description only states the function, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available vendors to purchase goods from using BulkClix payment. :param vendor_id: Vendor's UUID. If given, returns just that vendor. :param category: Vendor's category of goods (e.g. 'restaurant', 'food', 'airtime'). If given, filters vendors using case-insensitive substring and synonym expansion.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Vendor's category of goods (e.g. "restaurant", "food", "airtime"). If given, filters vendors using case-insensitive substring and synonym expansion. | |
| vendor_id | No | Vendor's UUID. If given, returns just that vendor. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: filtering by vendor_id or category with case-insensitive substring and synonym expansion, and the BulkClix payment context. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence stating the main purpose, followed by parameter documentation. No unnecessary words, yet all key details are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two optional parameters, existing output schema, and annotations, the description covers purpose, parameter semantics, and context. No gaps remain for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful semantics beyond schema: explains synonym expansion and case-insensitive substring for category, and that vendor_id returns just that vendor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), resource ('available vendors'), and context ('using BulkClix payment'). It distinguishes from sibling tools like get_verified_vendors_menu and list_vendor_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing vendors but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Yango booking link for a delivery between two points. The customer opens this link to confirm pickup/dropoff and pricing in the Yango app — pricing and order placement happen on Yango's side, not through this server, until direct API access is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| pickup_lat | Yes | ||
| pickup_lon | Yes | ||
| dropoff_lat | Yes | ||
| dropoff_lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description adds context that pricing and order placement happen on Yango's side, not through this server. This clarifies the non-destructive, link-generating nature. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and each sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so missing return value description is acceptable. However, the tool interacts with an external service (Yango), and the description lacks details on prerequisites (e.g., Yango app, region) or external dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'between two points' without explaining the coordinate parameters (pickup_lat, etc.). It fails to add meaning beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a Yango booking link for a delivery between two points, and distinguishes from sibling tools (e.g., airtime, data, food) by specifying the Yango-specific purpose. It uses a specific verb ('get') and resource ('Yango delivery link').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use the tool: to get a link for a delivery. It implies it's not for direct API access by noting 'until direct API access is enabled'. No explicit alternatives or exclusions are given, but the context of siblings suggests it's unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all categories of goods (e.g. 'restaurant', 'food', 'airtime', 'data') supported by the verified vendors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition of 'supported by the verified vendors' provides minor context. No behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'List', no waste. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema (not shown), the description sufficiently explains what the tool returns. Could hint at ordering or uniqueness, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema has no properties), so the description does not need to explain them. The examples add value, meriting above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all categories of goods...' with concrete examples ('restaurant', 'food', 'airtime', 'data'), making the purpose clear and differentiating it from sibling tools that deal with specific vendors or purchases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 given, but given the tool's simplicity (no parameters), the usage is implied. It does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a Mobile Money collection or transaction. :param transaction_id: The transaction ID returned during collection. :param payment_id: Optional payment record ID if you already have it.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | No | Optional payment record ID if you already have it. | |
| transaction_id | Yes | The transaction ID returned during collection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description supports by stating 'Check the status'. The description adds no contradictions and provides basic behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus parameter list, front-loaded with the core purpose. Every sentence is essential, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose and parameters. It could mention expected status values but is sufficient for a read-only check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 minor context beyond the schema by specifying that transaction_id comes from collection and payment_id is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks status of a Mobile Money collection or transaction, using a specific verb and resource. It distinguishes from sibling tools like data_check_status by specifying 'Mobile Money'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description implies usage after obtaining a transaction_id, but does not mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an OTP (One-Time Password) via Email. CRITICAL: The message parameter MUST contain the exact placeholder <%otp_code%>. If this placeholder is missing, the API call will fail with a 422 error. :param email: Recipient email address. :param subject: Email subject. :param message: Email body containing <%otp_code%> template (e.g. 'Your verification code is: <%otp_code%>'). :param expiry: OTP validity duration in minutes (default 5). :param length: Digit length of the OTP (default 4).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Recipient email address. | ||
| expiry | No | OTP validity duration in minutes (default 5). | |
| length | No | Digit length of the OTP (default 4). | |
| message | Yes | Email body containing `<%otp_code%>` template (e.g. 'Your verification code is: <%otp_code%>'). | |
| subject | Yes | Email subject. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral details: the mandatory placeholder requirement, the explicit error condition (422), and default values for expiry and length. This goes well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose but well-structured: it opens with a critical warning, then lists parameters in a consistent format. Every sentence provides value, though a slight reduction in length could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5 parameters (3 required), the presence of an output schema, and no nested objects, the description covers all necessary behavioral aspects: failure conditions, defaults, and parameter constraints. It is complete enough for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already covers 100% of parameters, the description enriches understanding by emphasizing the critical placeholder requirement for the message parameter, providing an example, and clarifying default values. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an OTP (One-Time Password) via Email,' which is a specific verb+resource combination. The tool name itself distinguishes it from siblings like otp_send_sms and otp_verify_email, and the description reinforces this by specifying the email channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the message parameter must contain <%otp_code%> or the call will fail with a 422 error. However, it does not explicitly state when to use this tool versus alternative OTP delivery methods (e.g., SMS). The context from sibling tool names implies the distinction, but explicit guidance would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an OTP (One-Time Password) via SMS. CRITICAL: The message parameter MUST contain the exact placeholder <%otp_code%>. If this placeholder is missing, the API call will fail with a 422 error. :param phone_number: Recipient phone number (e.g. '0541000000'). :param message: Message template containing <%otp_code%> (e.g. 'Your verification code is: <%otp_code%>'). :param expiry: OTP validity duration in minutes (default 5). :param length: Digit length of the OTP (default 4).
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | No | OTP validity duration in minutes (default 5). | |
| length | No | Digit length of the OTP (default 4). | |
| message | Yes | Message template containing `<%otp_code%>` (e.g. 'Your verification code is: <%otp_code%>'). | |
| phone_number | Yes | Recipient phone number (e.g. '0541000000'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, confirming a write operation. The description adds behavior beyond annotations: the mandatory placeholder, failure condition (422 error), and parameter defaults (expiry=5, length=4). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats schema parameter descriptions, making it longer than necessary. It front-loads the critical requirement, but the Python docstring style (e.g., ':param ...') adds redundancy. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (OTP sending), annotations, and the presence of an output schema (not shown), the description covers the core functionality, failure mode, and parameter details. It does not describe the return value, but the output schema likely does that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 extra value by emphasizing the critical nature of <%otp_code%> in the message parameter, which is not highlighted in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'OTP via SMS'. It distinguishes from sibling tools like otp_send_email and otp_verify_sms by specifying the channel and the critical placeholder requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical guideline: the message must contain <%otp_code%> or the call fails with 422. It does not explicitly compare to alternatives (e.g., otp_send_email), but the name and context imply the use case for SMS OTP delivery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an OTP code that was sent via Email. :param request_id: The requestId returned from sending the OTP. :param email: The email address the OTP was sent to. :param code: The verification code to verify.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The verification code to verify. | |
| Yes | The email address the OTP was sent to. | ||
| request_id | Yes | The requestId returned from sending the OTP. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive. Description adds no further behavioral context (e.g., rate limits, idempotency, error behavior). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded, but includes redundant parameter documentation that already exists in the schema, adding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes the operation and all required parameters. Lacks usage guidelines but is otherwise complete for a straightforward verification tool with good annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Tool description merely repeats param docs, adding no extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Verify an OTP code that was sent via Email' with specific verb and resource, distinguishing it from sibling tools like otp_verify_sms and otp_send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through parameter descriptions (e.g., request_id from sending OTP), but no explicit when-to-use or when-not-to-use guidance, especially relative to otp_verify_sms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an OTP code that was sent via SMS. :param request_id: The requestId returned from sending the OTP. :param phone_number: The phone number the OTP was sent to. :param code: The code input by the user to check.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code input by the user to check. | |
| request_id | Yes | The requestId returned from sending the OTP. | |
| phone_number | Yes | The phone number the OTP was sent to. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=false, destructiveHint=false) but adds no additional behavioral details beyond the basic operation. The agent is not informed about side effects like OTP consumption or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes redundant param definitions that are already in the schema. It could be more structured by omitting the param lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is adequate but does not mention error conditions or return value semantics. It is complete for basic use but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented. The description redundantly repeats these details in a :param format, adding no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Verify an OTP code that was sent via SMS.' This is a specific verb (verify) and resource (SMS OTP), and it distinguishes itself from siblings like otp_verify_email and otp_send_sms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after sending an SMS OTP but does not explicitly state when to use this tool versus alternatives like otp_verify_email. No 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.
Verify a payment OTP after the customer reads the code from their phone and sends it in chat. CRITICAL: This is ONLY for validating payment-related transactions. The request_id MUST be the one returned in the response of a payment/purchase initiation tool (e.g., airtime_purchase, data_purchase, or momo_collect), NOT from otp_send_sms. Providing a standard SMS OTP request ID will result in a 404 Error. :param code: OTP code entered by the customer from their phone. :param request_id: Request ID returned from the payment/purchase initiation response. :param phone_number: The phone number used for the payment transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | OTP code entered by the customer from their phone. | |
| request_id | Yes | Request ID returned from the payment/purchase initiation response. | |
| phone_number | Yes | The phone number used for the payment transaction. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=true. The description adds no additional behavioral context beyond what the annotations convey. It does not contradict annotations but also does not elaborate on side effects or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and critical note. It includes parameter descriptions but is slightly verbose with the colon-formatted param list. Every sentence adds value, but it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are documented elsewhere), the description covers purpose, usage guidelines, parameter semantics, and critical warnings. It is fully self-contained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 reinforces the source of request_id beyond the schema, emphasizing it must come from payment initiation responses, not from otp_send_sms. This adds valuable context that helps avoid errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Verify a payment OTP' and the context 'after the customer reads the code from their phone and sends it in chat'. It explicitly distinguishes from sibling tools like otp_verify_sms by specifying that the request_id must come from payment initiation tools, not from otp_send_sms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: when to use (for validating payment-related transactions), when not to use (not with standard SMS OTP request IDs), and specifies the source of request_id (payment/purchase initiation responses). It also warns about the 404 error for incorrect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a food order directly with a restaurant merchant. Creates an order record in MongoDB, triggers MoMo payment collection from customer, and sends an order SMS dispatch to the merchant.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| amount_ghc | Yes | ||
| customer_name | Yes | ||
| payment_phone | No | ||
| customer_phone | Yes | ||
| payment_network | No | MTN | |
| delivery_address | Yes | ||
| restaurant_phone | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it creates a database record, triggers payment collection, and sends an SMS. This is useful information that annotations (readOnlyHint=false, destructiveHint=false) do not provide. It does not disclose failure behavior or idempotency, but overall adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no fluff or redundant information. It efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, 6 required, no schema descriptions), the description is incomplete. It lacks parameter explanations, usage context, and does not mention return values despite having an output schema. Sibling differentiation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 individual parameters like 'payment_phone', 'payment_network', or 'amount_ghc'. While it mentions a few fields descriptively, it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (place), the resource (food order with merchant), and lists three sub-actions (MongoDB record, MoMo payment, SMS dispatch). This distinguishes it from sibling tools like 'create_verified_vendors_order' and 'track_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. It does not mention prerequisites, conditions, or contexts where this tool is preferred over siblings like 'create_verified_vendors_order' or 'search_food_menus'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save or update a customer profile in MongoDB, including delivery address, landmark, and default MoMo payment number.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| landmark | No | ||
| phone_number | Yes | ||
| customer_name | Yes | ||
| default_payment_phone | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-readonly, non-destructive mutation. The description adds that it includes specific fields, but does not clarify behavior for omitted fields (e.g., setting to null) or mention return value, despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 16-word sentence that is front-loaded with the verb and resource. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose but omits details on handling missing fields, validation, and return structure. The existence of an output schema mitigates the need for return description, but openWorldHint is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides the only parameter context by naming fields (address, landmark, default_payment_phone). However, it lacks format constraints, examples, or validation hints for parameters like phone_number or customer_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves or updates a customer profile in MongoDB, listing specific fields (address, landmark, MoMo payment number). It distinguishes itself from the sibling 'get_customer_profile' which is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies upsert behavior but does not explicitly specify when to use create vs update, nor does it contrast with other write tools like 'place_merchant_order'. No prerequisites or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for vendors (merchants), menu items, and MCP tools/capabilities semantically in a single query. Use this to resolve which tool to call, which vendor fits a concept, or what food/goods are available.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_n | No | ||
| vendor_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it is a semantic search across multiple domains, but does not elaborate on behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (documenting return values) and annotations covering safety, the description covers the overall purpose and use case. However, it lacks details on parameter behaviors and scope limitations, which would enhance completeness for a tool searching across three domains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning for parameters. It only implies the 'query' parameter is a semantic query, but does not explain 'top_n' or 'vendor_id' at all. This is insufficient for a tool with 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for vendors, menu items, and MCP tools/capabilities semantically in a single query. The verb 'Search' is specific, and the description distinguishes it from sibling tools like 'search_food_menus' by being broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to resolve which tool to call, which vendor fits a concept, or what food/goods are available. This provides clear context but does not include explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track real-time status and delivery details of an order from MongoDB.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Track' implying a read-only operation, but annotations indicate readOnlyHint=false, creating a contradiction. No additional behavioral context is provided (e.g., no mention of side effects, auth needs, or rate limits), and the openWorldHint=true is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the key action. However, it lacks necessary details, making it minimally adequate for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and one parameter, the description is incomplete. It does not explain the order_id parameter, the nature of 'real-time', or the fact that it applies specifically to MongoDB orders. The annotations hint at open-world behavior but are not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and a single parameter 'order_id', the description adds no meaning beyond its presence. It does not specify format, source, or constraints, leaving the agent with insufficient information to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Track', the resource 'order', and the scope 'real-time status and delivery details'. It distinguishes from sibling tools like 'data_check_status' or 'momo_check_status' by specifying 'from MongoDB', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, when-not-to-use, or compare with other status-checking tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0airtime_get_networksairtime_purchasecreate_verified_vendors_orderdata_check_statusdata_get_bundlesdata_get_offersdata_purchasefind_food_itemsget_customer_profileget_token_infoget_verified_vendorsget_verified_vendors_menuget_yango_delivery_linklist_vendor_categoriesmomo_check_statusotp_send_emailotp_send_smsotp_verify_emailotp_verify_smspay_verify_otpplace_merchant_ordersave_customer_profilesearchsearch_food_menustrack_orderTools have distinct purposes overall, but there is overlap among search tools (find_food_items, search_food_menus, search) and between order placement tools (create_verified_vendors_order, place_merchant_order). Descriptions help differentiate, but an agent might still misselect.
Most tools follow a verb_noun snake_case pattern (e.g., airtime_get_networks, data_purchase). However, there are minor deviations: 'pay_verify_otp' uses two verbs, and 'search' lacks a noun. Overall, the convention is fairly consistent.
With 25 tools, the server covers multiple domains (airtime, data, food ordering, OTP, profiles, search). This is slightly heavy but not excessive given the scope. Some tools could be consolidated (e.g., merging similar search tools).
The tool surface supports core workflows: airtime/data top-up, food ordering with payment, OTP verification, and customer profiles. Missing update/delete operations for orders and profiles are minor gaps; no dead ends for main use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and manage DialNexa AI voice agents, campaigns, calls, phone numbers, workflows, and more.
Communication stack for AI agents: SMS, AI voice calls, phone numbers, and account events.
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
40+ Lightning-paid AI tools for agents: calls, SMS, fax, voice, translation. No signup, no keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AnanseLabs-Org/ananse-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
