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., "@Pulse MCP Server track 500 tokens of usage for customer 'user_123'"
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.
MCP server for the Pulse usage-based billing platform.
Track metering events, manage customers, generate invoices, and more — directly from any MCP-compatible AI assistant (Claude, Cursor, Windsurf, etc.).
npx @beinfi/pulse-mcpSet your API key as an environment variable:
export PULSE_API_KEY=sk_live_...Add to your claude_desktop_config.json:
{
"mcpServers": {
"pulse": {
"command": "npx",
"args": ["-y", "@beinfi/pulse-mcp"],
"env": {
"PULSE_API_KEY": "sk_live_..."
}
}
}
}claude mcp add pulse -- npx -y @beinfi/pulse-mcpThen set your API key:
export PULSE_API_KEY=sk_live_...Related MCP server: PayPls MCP Server
track_event — Track a single usage event for a customer
track_events_batch — Track multiple usage events in a single request
get_usage — Query aggregated usage data with optional filters
list_products — List all products
get_product — Get product details including its meters
create_product — Create a new product
create_meter — Create a meter (usage dimension) for a product
list_customers — List all customers for a product
create_customer — Create a new customer
update_customer — Update customer details
list_invoices — List invoices for a product
generate_invoice — Generate an invoice for a customer's usage period
get_invoice — Get invoice details
send_invoice — Send an invoice via email
list_payment_links — List all payment links
create_payment_link — Create a new payment link
get_payment_link — Get payment link details
list_payment_intents — List payment intents for a link
list_received_payments — List all received payments
list_my_agents — List your published AI agents
get_agent_usage — Get usage stats for an agent
invoke_agent — Invoke an AI agent with text input
list_webhooks — List all webhook subscriptions
create_webhook — Create a webhook subscription
delete_webhook — Delete a webhook subscription
Environment Variable | Required | Default | Description |
| Yes | — | Your Pulse API key ( |
| No |
| API base URL |
MIT
Create a new customer for a product
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| externalId | Yes | Your unique identifier for this customer | |
| name | No | Customer name | |
| No | Customer email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions required, whether creation is idempotent, what happens on duplicate externalId, or the response format, which are critical for a mutation tool.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, return values, or side effects, leaving significant gaps for the agent to operate effectively.
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 schema fully documents all parameters. The description adds no additional meaning beyond implying a relationship between customer and product, which is already clear from parameter names. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Create') and resource ('new customer for a product'), making the purpose immediately understandable. It distinguishes from siblings like 'create_product' by specifying the customer entity, though it doesn't explicitly contrast with 'update_customer' or 'list_customers'.
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 versus alternatives like 'update_customer' or 'list_customers'. The description lacks context about prerequisites, such as needing an existing product, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a meter (usage dimension) for a product
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| name | Yes | Meter identifier (e.g. 'api_calls', 'tokens') | |
| displayName | Yes | Human-readable meter name | |
| unit | Yes | Unit of measurement (e.g. 'request', 'token') | |
| unitPrice | Yes | Price per unit (e.g. '0.001') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'create' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether this is idempotent, what happens on duplicate names, error conditions, or rate limits. For a creation tool with zero annotation coverage, this is insufficient.
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, efficient sentence that front-loads the core purpose. There's zero waste or redundancy. It's appropriately sized for a tool with good schema documentation.
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 this is a creation/mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a successful creation returns, error handling, or important behavioral context. The 100% schema coverage helps with inputs, but overall context for safe/effective use is lacking.
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 schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond implying the meter is for a 'usage dimension', which is already suggested by parameter examples like 'api_calls' and 'tokens'. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('create') and resource ('meter for a product'), specifying it's for a 'usage dimension'. It distinguishes from siblings like create_product or create_customer by focusing on meters specifically. However, it doesn't explicitly contrast with other meter-related tools (none exist in siblings), so it's not a perfect 5.
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 is provided. The description doesn't mention prerequisites, dependencies, or scenarios where this is appropriate versus other creation tools like create_product. It's a basic statement of function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new payment link that customers can use to pay
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Payment link title | |
| description | No | Description shown to payer | |
| amount | Yes | Amount to charge (e.g. '29.99') | |
| currency | No | Currency code (USD or BRL, defaults to USD) |
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 states the tool creates a payment link but doesn't cover critical aspects like whether this is a write operation (implied by 'Create'), permission requirements, rate limits, idempotency, or what the response includes. This leaves significant gaps for a mutation tool.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error handling), usage context, and return values, which are essential for an AI agent to invoke it correctly and safely.
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 schema fully documents all 4 parameters. The description adds no additional meaning beyond what's in the schema, such as examples or constraints not covered. Baseline score of 3 is appropriate as the schema handles parameter documentation 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 action ('Create') and resource ('new payment link'), specifying its purpose for customer payments. It distinguishes from siblings like 'generate_invoice' or 'send_invoice' by focusing on payment links, but doesn't explicitly contrast with 'list_payment_links' or 'get_payment_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?
No guidance is provided on when to use this tool versus alternatives like 'generate_invoice' or 'send_invoice', nor does it mention prerequisites such as authentication or setup requirements. The description implies usage for creating payment links but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product for usage metering
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Product name | |
| type | No | Product type (e.g. 'saas', 'api') | |
| description | No | Product description |
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 states the tool creates a product but doesn't disclose behavioral traits such as required permissions, whether the operation is idempotent, what happens on failure, or the format of the response (since no output schema exists). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part earning its place by specifying the action, resource, and context.
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 (a creation operation with 3 parameters), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and response format. It meets the minimum viable threshold but has clear gaps in completeness for a mutation 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 description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with clear descriptions for name, type, and description. Since schema_description_coverage is high, the baseline is 3. The description doesn't provide additional context like example values for 'type' or constraints 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 action ('Create') and resource ('new product'), specifying it's for 'usage metering'. This distinguishes it from other creation tools like create_customer or create_meter by focusing on products. However, it doesn't explicitly differentiate from get_product or list_products, which would require more specificity about the creation 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a customer or meter first), when not to use it (e.g., for updating existing products), or refer to sibling tools like get_product or list_products for related operations. Usage is implied only by the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a webhook subscription to receive event notifications
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to receive webhook POST requests | |
| events | Yes | Array of event types to subscribe to (e.g. ['payment.completed', 'invoice.sent']) |
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 states the tool creates a subscription but lacks details on permissions required, whether it's idempotent, rate limits, what happens on duplicate subscriptions, or the response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by clearly stating the tool's function, making it highly concise 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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error handling, or what the tool returns (e.g., a webhook ID). For a tool that creates resources, more context is needed to guide effective use.
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 schema description coverage is 100%, so the input schema fully documents both parameters ('url' and 'events'). The description adds no additional meaning beyond what's in the schema (e.g., no examples beyond the schema's event types, no format constraints). Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('Create a webhook subscription') and resource ('to receive event notifications'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_webhook' or 'list_webhooks' beyond the verb, missing an opportunity for clearer sibling distinction.
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 doesn't mention prerequisites (e.g., needing a valid URL or specific permissions), when not to use it (e.g., for one-time events vs. subscriptions), or refer to related tools like 'list_webhooks' or 'delete_webhook' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook subscription
| Name | Required | Description | Default |
|---|---|---|---|
| webhookId | Yes | The webhook subscription ID to delete |
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 states the action ('Delete') but doesn't disclose critical traits like whether this is destructive (implied by 'Delete'), what permissions are required, if the deletion is reversible, or any rate limits. The description is minimal and fails to add meaningful context beyond the basic action, leaving significant gaps in understanding the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This level of conciseness is ideal for a simple tool with a clear action, though it comes at the cost of missing additional helpful details.
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 (a destructive operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral traits, usage context, and output expectations, which are crucial for safe and effective tool invocation. The high schema coverage helps with parameters, but overall, the description doesn't provide enough context to fully understand the tool's role and implications.
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 100% description coverage, with the parameter 'webhookId' clearly documented as 'The webhook subscription ID to delete'. The description doesn't add any additional meaning or context beyond what the schema provides, such as format examples or sourcing instructions. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Delete') and the resource ('a webhook subscription'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'create_webhook' and 'list_webhooks' by specifying deletion rather than creation or listing. However, it doesn't explicitly mention what a webhook subscription is or its scope, which could slightly limit clarity for users unfamiliar with the 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 provides no guidance on when to use this tool versus alternatives, such as when to delete versus update or list webhooks. It doesn't mention prerequisites (e.g., needing an existing webhook ID) or exclusions, leaving the agent to infer usage from the tool name alone. This lack of explicit context reduces its effectiveness in guiding tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an invoice for a customer's usage in a given period
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| customerId | Yes | The customer's external ID | |
| periodStart | Yes | Billing period start (ISO 8601 date) | |
| periodEnd | Yes | Billing period end (ISO 8601 date) |
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 states the tool generates an invoice, implying a creation/mutation operation, but fails to mention critical details like whether this triggers billing, requires specific permissions, or what the output format might be. This is a significant gap for a tool that likely modifies system state.
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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
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 likely creates an invoice (a mutation with financial implications), the lack of annotations and output schema means the description should do more to explain behavior, output, or error conditions. It's incomplete for a tool that interacts with billing data, as it omits details on what happens post-generation or how failures are handled.
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 description mentions 'customer's usage' and 'given period', which loosely maps to the 'customerId', 'periodStart', and 'periodEnd' parameters, but doesn't add meaningful semantics beyond what the schema already provides (e.g., it doesn't clarify how 'productId' relates to usage or invoice generation). With 100% schema description coverage, the baseline is 3, and the description adds minimal extra 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 the action ('generate an invoice') and the target ('for a customer's usage in a given period'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_invoice' or 'send_invoice', which handle retrieval and delivery respectively, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_invoice' or 'send_invoice', nor does it mention prerequisites such as existing customer or product data. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get usage statistics for a specific agent by its slug
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent's URL slug |
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 states it 'gets' data, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or details the format of 'usage statistics'. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core action and resource efficiently, making it easy to parse. Every word earns its place, achieving optimal conciseness for this simple tool.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'usage statistics' includes (e.g., metrics, timeframes) or the return format, leaving the agent uncertain about the tool's output. For a tool with no structured output documentation, the description should provide more context to be fully helpful.
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 100% description coverage, with the 'slug' parameter documented as 'The agent's URL slug'. The description adds no additional semantic context beyond this, such as examples or constraints on slug format. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 ('Get usage statistics') and resource ('for a specific agent by its slug'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_usage' or 'list_my_agents', which might also retrieve usage or agent information, so it doesn't reach the highest score.
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 doesn't mention prerequisites, such as needing an existing agent slug, or compare it to siblings like 'get_usage' (which might retrieve general usage) or 'list_my_agents' (which lists agents). This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific invoice
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| invoiceId | Yes | The invoice ID |
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 implies a read-only operation ('Get') but doesn't specify authentication needs, rate limits, error conditions, or what 'detailed information' includes (e.g., line items, dates, status). This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves detailed information. It doesn't explain what 'detailed information' entails, potential return formats, or error handling, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 100% description coverage, clearly documenting both required parameters ('productId' and 'invoiceId'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or relationships between parameters, so it meets the baseline for high schema coverage.
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's purpose with a specific verb ('Get') and resource ('detailed information about a specific invoice'), making it easy to understand what it does. However, it doesn't differentiate from sibling tools like 'list_invoices' or 'generate_invoice', which would require mentioning it retrieves existing invoice details rather than creating or listing multiple invoices.
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 doesn't mention prerequisites (e.g., needing a specific invoice ID), contrast with 'list_invoices' for multiple invoices, or specify use cases like retrieving details for payment processing or auditing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific payment link
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | Yes | The payment link ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like read-only nature, error handling, authentication needs, rate limits, or response format. This is inadequate for a tool with zero annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place, making it appropriately sized for a simple retrieval tool.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, error conditions, or behavioral constraints, which are critical for a tool with no structured data to supplement it.
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 description doesn't add meaning beyond the input schema, which has 100% coverage and fully documents the 'linkId' parameter. Since schema_description_coverage is high, the baseline is 3, and the description doesn't compensate with extra context about parameter usage or examples.
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 ('Get details about') and resource ('a specific payment link'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_payment_links' or 'get_invoice', which would require explicit comparison to earn a 5.
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 like 'list_payment_links' or other 'get_' tools. It lacks context about prerequisites (e.g., needing a linkId) or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific product including its meters
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation ('Get details'), but does not specify whether it requires authentication, rate limits, error handling, or what the return format includes beyond 'details' and 'meters'. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and scope, making it easy to parse and understand quickly. There is no wasted verbiage or structural issues.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves product details. It does not explain what 'details' or 'meters' entail, potential error conditions, or authentication requirements. For a read operation with no structured output information, more context is needed to guide the agent effectively.
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 schema description coverage is 100%, with the parameter 'productId' fully documented in the input schema. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or constraints. Since the schema handles the parameter documentation adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific product including its meters.' It specifies the verb ('Get'), resource ('product'), and scope ('details' and 'meters'). However, it does not explicitly differentiate from sibling tools like 'list_products' or 'get_usage', which slightly limits its clarity in distinguishing use cases.
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, such as needing a product ID, or contrast it with sibling tools like 'list_products' for browsing or 'get_usage' for usage data. This lack of contextual usage information leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query aggregated usage data, optionally filtered by product, customer, or date range
| Name | Required | Description | Default |
|---|---|---|---|
| productId | No | Filter by product ID | |
| customerId | No | Filter by customer external ID | |
| startDate | No | Start date (ISO 8601) | |
| endDate | No | End date (ISO 8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions querying aggregated data but fails to specify critical traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or the format of returned data. This leaves significant gaps for an AI agent to understand how the tool behaves.
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, efficient sentence that front-loads the core action ('Query aggregated usage data') and succinctly lists optional filters. There is no wasted text, making it highly concise and well-structured for quick comprehension.
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 complexity of a query tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'aggregated usage data' entails, the response format, or any behavioral aspects like error handling. This makes it inadequate for an AI agent to fully understand the tool's context and 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?
The input schema has 100% description coverage, clearly documenting all four parameters (productId, customerId, startDate, endDate) with their types and purposes. The description adds minimal value beyond this by listing the filter options but doesn't provide additional semantics like examples or constraints, so it meets the baseline for high schema coverage.
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's purpose with the verb 'Query' and resource 'aggregated usage data', making it specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_agent_usage', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning optional filters (product, customer, date range), suggesting when to apply them, but it lacks explicit guidance on when to use this tool versus alternatives like 'get_agent_usage' or 'track_event'. No exclusions or prerequisites are stated, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke an AI agent from the Pulse marketplace with a text input
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent's URL slug | |
| input | Yes | The text input to send to the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions 'invoke' which implies an action, but doesn't disclose what happens during invocation (e.g., does it trigger a process, return immediate results, require specific permissions, have rate limits, or produce side effects?). The description lacks essential behavioral context for an invocation tool.
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, efficient sentence that gets straight to the point. It's appropriately sized for a tool with two parameters and no complex behavior described. There's no wasted verbiage, though it could potentially benefit from being slightly more informative given the lack of annotations.
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 an invocation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'invoke' means operationally, what kind of response to expect, whether this is a synchronous or asynchronous operation, or any error conditions. The description leaves too many open questions about how this tool actually behaves in practice.
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 schema already documents both parameters ('slug' and 'input') adequately. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what constitutes a valid 'slug' format, provide examples, or clarify the nature of the 'input' parameter. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('invoke') and resource ('AI agent from the Pulse marketplace') with a specific input type ('text input'). It distinguishes this from sibling tools which are all related to billing/customer management, but doesn't explicitly differentiate from similar potential tools like 'get_agent_usage' or 'list_my_agents'.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, when this should be used instead of other agent-related tools, or any contextual constraints. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all customers for a product
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID |
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 states the tool lists customers but doesn't disclose behavioral traits like whether it's read-only, paginated, rate-limited, or requires authentication. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place, making it highly concise 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., customer details, pagination), behavioral aspects, or usage context. For a tool with no structured data to compensate, this 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'productId' documented as 'The product ID'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 all customers') and the resource ('for a product'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_invoices' or 'list_products' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_customer' (if it existed) or other list tools. It lacks context about prerequisites, such as needing a valid product ID, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List invoices for a product, optionally filtered by status
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| status | No | Filter by invoice status (e.g. 'draft', 'sent', 'paid') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation with filtering, but doesn't disclose behavioral traits like whether it's read-only (implied but not explicit), pagination behavior, rate limits, authentication needs, or what happens if no invoices exist. For a list tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('List invoices for a product') and adds optional filtering as a concise modifier. Every word earns its place, making it easy to parse.
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 no annotations, no output schema, and a list operation with filtering, the description is incomplete. It doesn't explain return values (e.g., format, fields), error conditions, or behavioral constraints like pagination. For a tool with 2 parameters and no structured output documentation, more context is needed to be fully helpful.
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 schema already documents both parameters ('productId' and 'status') with descriptions. The description adds marginal value by mentioning 'optionally filtered by status', which aligns with the schema but doesn't provide additional syntax or format details beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 invoices') and resource ('for a product'), with optional filtering by status. It distinguishes from siblings like 'get_invoice' (singular retrieval) and 'generate_invoice' (creation). However, it doesn't explicitly differentiate from other list tools like 'list_customers' or 'list_products' beyond the resource type.
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 context by specifying 'for a product' and optional status filtering, suggesting it's for retrieving multiple invoices. However, it lacks explicit guidance on when to use this versus alternatives like 'get_invoice' for single invoices or 'list_received_payments' for payment-related lists. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AI agents you've published in the Pulse marketplace
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what the tool does, not how it behaves. It lacks details on permissions, rate limits, pagination, or response format, which are critical for a list operation. No contradictions exist, but transparency is minimal.
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, efficient sentence that front-loads the purpose without any wasted words. It is appropriately sized for a simple list tool with no parameters, making it easy to parse.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks behavioral context like response structure or usage constraints, which could hinder effective agent invocation.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately omits parameter details, aligning with the schema, though it doesn't add extra semantics beyond the implied scope.
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 specific action ('List all AI agents') and resource ('you've published in the Pulse marketplace'), distinguishing it from siblings like list_customers or list_products. It precisely defines scope without being vague or tautological.
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 versus alternatives like get_agent_usage or invoke_agent. The description implies usage for listing published agents but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payment intents (attempted payments) for a specific payment link
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | Yes | The payment link ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'payment intents (attempted payments)', hinting at a read-only list of pending transactions, but fails to disclose critical details like authentication needs, rate limits, pagination, return format, or error conditions. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function, making it easy to parse and understand quickly.
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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks information on behavioral traits (e.g., safety, side effects), output structure, and usage nuances, leaving significant gaps for an AI agent to rely on.
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 description does not add parameter details beyond the schema, which has 100% coverage for the single 'linkId' parameter. The baseline is 3 since the schema fully documents the parameter, and the description does not compensate with additional context like format examples or usage notes.
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') and resource ('payment intents'), specifying they are 'attempted payments' for a 'specific payment link'. It distinguishes from siblings like 'list_received_payments' by focusing on intents rather than completed payments, but does not explicitly differentiate from other list tools like 'list_payment_links'.
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 context by specifying 'for a specific payment link', suggesting it should be used when querying intents linked to a particular link. However, it lacks explicit guidance on when to choose this over alternatives like 'list_received_payments' or 'get_payment_link', and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all payment links in your account
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20) | |
| offset | No | Number of results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List all payment links' implies a read-only operation, it doesn't mention pagination behavior (implied by limit/offset parameters), authentication requirements, rate limits, or what 'all' means in practice (e.g., active only, includes archived). The description is minimal and lacks important operational 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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple listing tool and gets straight to the point.
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 listing tool with 2 parameters and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about payment links, how results are ordered, whether filtering options exist, or what happens when no payment links are found. The lack of annotations exacerbates these gaps in operational understanding.
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%, with both parameters (limit and offset) clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without adding 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 the verb ('List') and resource ('all payment links in your account'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling list tools like list_customers or list_invoices, which follow the same pattern but target different resources.
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. There are multiple sibling list tools (e.g., list_customers, list_invoices) and a specific get_payment_link tool for retrieving individual payment links, but the description doesn't mention any of these or provide context about when this listing approach is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products in your Pulse account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the action but doesn't describe what 'list' means operationally - whether it returns all products at once, uses pagination, requires specific permissions, has rate limits, or what format the output takes. This is inadequate for a tool with zero annotation coverage.
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, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality.
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 no annotations, no output schema, and the description's minimal content, this is incomplete for operational use. While the purpose is clear, the agent lacks crucial information about behavior, output format, pagination, permissions, or error conditions that would be needed to use this tool effectively.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 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 clearly states the action ('List all products') and resource ('in your Pulse account'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'get_product' which retrieves a single product, missing an opportunity for sibling differentiation.
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 like 'get_product' (for single product retrieval) or other list_* siblings. There's no mention of prerequisites, context, or exclusions, leaving usage decisions entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all received payments across all payment links
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20) | |
| offset | No | Number of results to skip |
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 mentions 'list all received payments' but doesn't cover aspects like pagination behavior (implied by limit/offset), rate limits, authentication needs, or what the return format looks like. This leaves significant gaps for a tool that likely involves sensitive financial data.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 complexity of listing financial payments with no annotations and no output schema, the description is insufficient. It lacks details on return values, error handling, or behavioral traits like data sensitivity or access controls, which are critical for such a tool in a payment system context.
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%, with both 'limit' and 'offset' parameters well-documented in the schema. The description doesn't add any meaning beyond this, such as explaining how pagination works or default values beyond what's in the schema, so it meets the baseline for high schema coverage.
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 'list' and resource 'received payments' with scope 'across all payment links', making the purpose evident. However, it doesn't differentiate from sibling tools like 'list_payment_intents' or 'list_invoices', which might also list payment-related data, so it's not fully specific to sibling 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?
No guidance is provided on when to use this tool versus alternatives such as 'list_payment_intents' or 'get_invoice', nor are any prerequisites or exclusions mentioned. The description only states what it does without context for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhook subscriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation but doesn't disclose details like pagination, rate limits, authentication requirements, or response format. For a tool with zero annotation coverage, this is inadequate, as it leaves critical behavioral traits unspecified.
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, direct sentence with zero wasted words. It front-loads the core action ('list all webhook subscriptions') efficiently, making it easy to parse. Every word earns its place, achieving optimal conciseness for such a simple tool.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of webhooks. It doesn't explain what data is returned, handling of errors, or system constraints. For a list operation with no structured output documentation, more context is needed to guide the agent effectively.
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 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as no additional semantics are needed beyond the schema's clear indication of no inputs.
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 ('list') and resource ('webhook subscriptions'), making the purpose immediately understandable. It distinguishes from siblings like create_webhook and delete_webhook by indicating a read operation. However, it doesn't specify scope (e.g., 'all' is implied but not explicit about filtering or pagination), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., authentication), compare to other list tools (e.g., list_customers), or indicate use cases (e.g., checking existing subscriptions before creating/deleting). This leaves the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send (or re-send) an invoice via email to the customer
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| invoiceId | Yes | The invoice ID |
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 mentions the action ('send or re-send') but doesn't cover critical aspects like whether this requires specific permissions, if it's idempotent, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by contributing essential information about 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 that this is a mutation tool with no annotations, no output schema, and incomplete behavioral context, the description is insufficient. It lacks details on permissions, idempotency, error handling, or what the tool returns, which are critical for an agent to use it correctly and safely in a production environment.
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 schema already documents both parameters ('productId' and 'invoiceId') adequately. The description doesn't add any meaningful parameter semantics beyond what the schema provides, such as explaining the relationship between product and invoice or format requirements. The baseline 3 is appropriate when the schema does the heavy lifting.
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 ('send or re-send') and resource ('invoice via email to the customer'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential siblings like 'generate_invoice' or 'get_invoice', which would require more differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., invoice must exist), when re-sending is appropriate, or how it differs from related tools like 'generate_invoice' or 'get_invoice', leaving the agent with insufficient context for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track a single usage event for a customer
| Name | Required | Description | Default |
|---|---|---|---|
| meterId | Yes | The meter ID to track against | |
| customerId | Yes | The customer's external ID | |
| value | Yes | The usage value (e.g. '1', '1500') | |
| timestamp | No | ISO 8601 timestamp (defaults to now) | |
| metadata | No | Optional metadata key-value pairs |
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 states the action ('track') but doesn't clarify if this is a write operation, what permissions are needed, how errors are handled, or if it's idempotent. This leaves significant gaps for a tool that likely mutates data.
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, direct sentence that efficiently conveys the core action without any fluff or redundancy. It's appropriately sized and front-loaded with essential 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?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value, error conditions, or behavioral nuances, leaving the agent with incomplete guidance for proper invocation.
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 description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for all parameters. This meets the baseline for adequate but unenriched parameter context.
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') and resource ('a single usage event for a customer'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'track_events_batch', which handles multiple events, leaving some room for confusion.
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 like 'track_events_batch' for multiple events or 'get_usage' for retrieval. It lacks context about prerequisites or typical scenarios, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track multiple usage events in a single request
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | Array of events to track |
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 mentions the batch behavior but doesn't disclose critical traits like whether this is a write operation, authentication needs, rate limits, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('track multiple usage events') with no wasted words. It's appropriately sized for the tool's complexity.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits, return values, error conditions, or integration context, making it inadequate for safe and effective use by an AI agent.
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%, with the 'events' parameter fully documented in the schema. The description adds no additional parameter semantics beyond implying batch tracking, so it meets the baseline of 3 where the schema does the heavy lifting.
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') and resource ('multiple usage events') with the specific context of batching ('in a single request'). It distinguishes from the sibling 'track_event' by emphasizing the batch capability, though it doesn't explicitly name the sibling.
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 tracking multiple events is needed versus single events, but doesn't explicitly state when to use this tool versus 'track_event' or mention any prerequisites, alternatives, or exclusions. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing customer's details
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The product ID | |
| customerId | Yes | The customer ID | |
| name | No | Updated customer name | |
| No | Updated customer email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Update' implies mutation, but it doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('update,' 'existing customer,' 'details') earns its place, making it easy to parse quickly.
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 (mutation with 4 parameters), lack of annotations, and no output schema, the description is inadequate. It doesn't cover behavioral aspects, usage context, or return values, leaving critical gaps for an agent to invoke it 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 schema already documents all parameters. The description adds no additional meaning beyond implying 'details' might include name and email, which the schema already specifies. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('update') and resource ('existing customer's details'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_customer' or specify what 'details' encompasses beyond what's in the schema.
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 versus alternatives like 'create_customer' or 'list_customers'. The description lacks context about prerequisites (e.g., customer must exist) or exclusions, leaving the agent to infer usage from the tool name alone.
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.
v0.1.0create_customercreate_metercreate_payment_linkcreate_productcreate_webhookdelete_webhookgenerate_invoiceget_agent_usageget_invoiceget_payment_linkget_productget_usageinvoke_agentlist_customerslist_invoiceslist_my_agentslist_payment_intentslist_payment_linkslist_productslist_received_paymentslist_webhookssend_invoicetrack_eventtrack_events_batchupdate_customerMost tools have clearly distinct purposes targeting specific resources and actions, such as create_customer vs. update_customer or track_event vs. track_events_batch. However, some potential ambiguity exists between list_payment_intents and list_received_payments, as both relate to payment tracking but with slightly different scopes that could confuse an agent about which to use for specific queries.
Tool names follow a highly consistent verb_noun pattern throughout, such as create_customer, list_products, get_usage, and update_customer. All tools use snake_case with clear action verbs, making the set predictable and easy to navigate without any deviations in naming conventions.
With 25 tools, the count is borderline high for a coherent set, as it may feel heavy and potentially overwhelming for an agent. While the tools cover a broad domain of billing, metering, and marketplace operations, the number approaches the upper limit where usability might degrade, placing it in the 16-25 range that feels borderline for typical agent interactions.
The tool set provides comprehensive coverage for billing, metering, and marketplace domains, including CRUD operations for customers, products, and webhooks, plus usage tracking and payment management. Minor gaps exist, such as no update or delete tools for products or meters, but agents can likely work around these with the available create and get operations without significant failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Be-Infinitum/pulse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
