Usage And Billing MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes targeting specific resources like meters, products, plans, and usage, with minimal overlap. However, 'get_account_customer' and 'get_accounts_customers' could cause minor confusion due to similar naming, and 'health_check' is a utility that stands apart from the core billing domain.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_meter, get_product) with clear CRUD operations, which aids predictability. A minor deviation is 'get_plans_of_a_product' which uses 'of_a' instead of a simpler pattern like 'get_product_plans', slightly breaking the consistency.
Tool Count4/5
With 18 tools, the count is reasonable for a billing and usage management domain, covering various entities like products, meters, and accounts. It's slightly on the higher side but well-scoped, as each tool serves a distinct function without appearing bloated.
Completeness4/5
The tool set provides comprehensive CRUD coverage for core resources (e.g., products, meters, usage) and includes utility functions like health checks. A minor gap is the lack of update or delete operations for meters, plans, and product items, which might require workarounds but doesn't severely hinder core workflows.
Average 2.1/5 across 18 of 18 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Get product' doesn't indicate whether this is a read-only operation, what authentication might be required, whether it has rate limits, what happens if the product doesn't exist, or what format the response takes. For a retrieval tool with zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Get product' is extremely brief, this represents under-specification rather than effective conciseness. The two words don't earn their place by providing meaningful information. A truly concise description would still convey essential context about what's being retrieved and for what purpose, which this completely lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a retrieval tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what a 'product' is in this context, what information is returned, whether there are any constraints or limitations, or how this differs from similar tools. For a tool that presumably returns important business data, this minimal description fails to provide the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'id' documented in the schema. The description adds no parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get product' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what 'product' refers to, what kind of retrieval operation this is, or how it differs from sibling tools like 'get_products' (plural). This provides no value beyond the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or differentiate from sibling tools like 'get_products' (which presumably retrieves multiple products) or 'get_product_item' (which retrieves product items). There's no indication of when this specific single-product retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description to disclose behavioral traits. 'Delete product' implies a destructive, irreversible mutation, but the description fails to specify permissions required, side effects (e.g., cascading deletions), error conditions, or confirmation prompts. This omission is critical for a tool with permanent consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with two words, the description is under-specified rather than efficiently structured. It lacks front-loaded critical information (e.g., irreversible action) and omits necessary context for safe use. Conciseness should not come at the expense of clarity, especially for destructive operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (destructive mutation) and absence of annotations or output schema, the description is severely incomplete. It does not address behavioral risks, success/error responses, or integration with sibling tools. For a delete operation, this minimal description fails to provide the necessary context for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter documented in the schema. The description adds no parameter semantics beyond what the schema provides, such as format examples or validation rules. However, with only one parameter and high schema coverage, the baseline score of 3 is appropriate as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete product' is a tautology that merely restates the tool name without adding meaningful context. It specifies the verb ('Delete') and resource ('product'), but lacks any distinction from sibling tools or elaboration on what 'product' refers to in this system. This minimal statement provides basic intent but fails to clarify scope or differentiate from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., product must exist), exclusions (e.g., cannot delete if in use), or refer to sibling tools like 'get_products' for verification. With no usage context, an agent cannot determine appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Get meters' doesn't indicate whether this is a read-only operation, what permissions might be required, whether it returns all meters or a filtered subset, what format the response takes, or any rate limits or constraints. The description provides zero behavioral context beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Get meters' is technically concise with only two words, this represents under-specification rather than effective conciseness. The description fails to provide necessary information about what the tool does, making it inefficient rather than appropriately brief. Every word should earn its place, but here the words don't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of having sibling tools with similar names (get_meter, get_products, etc.), no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'meters' are in this system, how this differs from get_meter, what the response contains, or any behavioral characteristics. For a tool in a family of similar retrieval operations, this minimal description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there are no parameters requiring documentation. The description doesn't need to explain any parameters, and the absence of parameter information in the description is appropriate for a zero-parameter tool. This meets the baseline expectation for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get meters' is a tautology that merely restates the tool name without adding any meaningful clarification. It doesn't specify what 'meters' refers to in this context or what the operation actually does. While it includes a verb ('Get'), it lacks specificity about what resource is being retrieved and provides no differentiation from sibling tools like 'get_meter' (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools with similar names (get_meter, get_products, get_product_items, etc.), but the description offers no context about when this specific tool is appropriate, what distinguishes it from get_meter, or any prerequisites for its use. This leaves the agent with no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states 'Get product item' without explaining what 'Get' entails—such as whether it's a read-only operation, requires authentication, has rate limits, or returns specific data formats. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get product item' is overly concise to the point of under-specification. It consists of three words with no structure or elaboration, failing to provide necessary context. While brief, it doesn't earn its place by adding value, making it inefficient rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what a 'product item' is, what data is returned, or how it differs from sibling tools. Without annotations or output schema, the description should compensate more to be complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Example value: ' (though incomplete). The description adds no additional meaning beyond the schema, such as clarifying what the 'id' represents or its format. With high schema coverage, the baseline is 3, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get product item' is a tautology that essentially restates the tool name with minimal elaboration. While it includes a verb ('Get') and resource ('product item'), it lacks specificity about what 'product item' means or how this differs from sibling tools like 'get_product_items' (plural) or 'get_product'. The purpose is vague and doesn't distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, nor does it differentiate from sibling tools like 'get_product_items' (which likely retrieves multiple items) or 'get_product' (which might retrieve product metadata). This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get product items' only indicates a read operation without any information about permissions required, rate limits, pagination behavior, error conditions, or what format the results will be in. For a tool with no annotation coverage, this description provides minimal behavioral insight beyond the basic operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically concise with just three words, it represents under-specification rather than effective conciseness. The description fails to provide necessary context and doesn't earn its place by adding value beyond the tool name. True conciseness balances brevity with information density, which this description lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's no output schema and no annotations, the description should provide more complete context about what this tool returns and how it behaves. The description is inadequate for a tool that presumably returns multiple product items based on a product_id parameter. It doesn't explain what constitutes 'items' or provide any context about the expected response format or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'product_id' documented in the schema. The description doesn't add any additional parameter information beyond what the schema provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get product items' is a tautology that essentially restates the tool name without adding meaningful context. It specifies the verb 'Get' and resource 'product items', but doesn't distinguish this tool from sibling tools like 'get_product_item' (singular) or clarify what 'items' refers to in this context. The description lacks specificity about scope or differentiation from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools including 'get_product_item' (singular), 'get_product', and 'get_products', there's no indication of how this tool differs in functionality or appropriate use cases. No context about prerequisites, limitations, or alternatives is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get Products' implies a read operation but offers no details on what it returns (e.g., list format, pagination), any side effects, error conditions, or performance considerations. This is inadequate for a tool with zero annotation coverage, as it fails to describe key 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Get Products' is brief, it is under-specified rather than concise. A single phrase without elaboration fails to provide necessary context, making it inefficient in conveying purpose. True conciseness balances brevity with clarity, which this description lacks due to its vagueness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'get' entails (e.g., returns a list, supports filtering), what 'products' are, or the expected output format. For a tool with no structured data to rely on, this minimal description fails to provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets the baseline. However, it doesn't add any value beyond the schema, but with no parameters to document, a score of 4 is appropriate as it doesn't introduce confusion or gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Products' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what 'get' means in this context (list, retrieve, fetch) or what 'products' refers to (type, scope, or format). While it matches the verb+resource pattern, it lacks the specificity needed to distinguish it from sibling tools like 'get_product' or 'get_product_items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it differentiate it from similar sibling tools such as 'get_product' (singular) or 'get_product_items'. This leaves the agent with no information to make an informed selection among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get Usage' reveals nothing about whether this is a read-only operation, what permissions are required, whether it has side effects, rate limits, or what the response format might be. For a tool with zero annotation coverage, this description is completely inadequate in describing 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Get Usage' is technically concise with only two words, it represents under-specification rather than effective conciseness. The description fails to convey essential information that would help an AI agent understand and use the tool correctly. Every word should earn its place, but here the minimal text doesn't fulfill the description's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a vague description, this tool definition is severely incomplete. The description doesn't explain what 'usage' means in this context, what data is returned, or how this tool differs from sibling tools like 'report_usage'. For a tool that presumably retrieves important usage data, this description provides insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. A baseline score of 4 is appropriate since there's no parameter information to provide beyond what the schema already indicates (no parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Usage' is a tautology that essentially restates the tool name without adding meaningful context. It doesn't specify what kind of usage is retrieved (e.g., API usage, billing usage, system usage) or what resource is being accessed. While it includes a verb ('Get'), it lacks specificity about the target resource or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools that might retrieve usage-related data (e.g., 'report_usage'), but the description doesn't differentiate this tool from them or indicate appropriate contexts for its use. No prerequisites, exclusions, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Report Usage' implies a read-only operation that might generate or output usage data, but it doesn't specify whether this is a safe operation, what permissions are required, how the report is formatted, or any side effects. The description fails to provide essential behavioral context beyond the vague action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Report Usage' is concise, it is under-specified rather than efficiently structured. The description consists of only two words and fails to convey necessary information about the tool's purpose or behavior. Conciseness should not come at the expense of clarity, making this score low due to inadequate content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely involves reporting usage data. It doesn't explain what the tool returns, how it behaves, or any operational constraints. For a tool in a context with many sibling tools (e.g., 'get_usage'), more detail 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional information is required or provided, which is appropriate given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report Usage' is a tautology that merely restates the tool name without adding any meaningful clarification. It doesn't specify what kind of usage is being reported, to whom, or what the report contains. While it indicates a reporting function, it lacks the specificity needed to distinguish it from sibling tools like 'get_usage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it differentiate it from sibling tools such as 'get_usage' or others that might handle usage-related operations. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get accounts' implies a read operation but doesn't specify any behavioral traits such as whether it requires authentication, returns paginated results, has rate limits, or what format the output takes. The description is too vague to inform the agent about how the tool behaves beyond the basic implication of retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, but this brevity comes at the cost of under-specification. While it's front-loaded and wastes no words, it fails to provide essential information that would help an AI agent use the tool effectively. Conciseness should not sacrifice clarity, and here it does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely retrieves data. It doesn't explain what 'accounts' are, how results are returned, or any constraints. While the zero-parameter schema simplifies input, the description fails to compensate for missing behavioral and output context, leaving 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. This meets the baseline expectation for a tool with no parameters, as it avoids unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get accounts' is a tautology that essentially restates the tool name 'get_accounts_customers' without adding meaningful specificity. It doesn't clarify what 'accounts' refers to (e.g., customer accounts, billing accounts) or distinguish this tool from sibling tools like 'get_account_customer' (singular) or 'get_my_account_profile'. The verb 'Get' is generic and doesn't specify the operation's scope or nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and fails to differentiate it from similar sibling tools like 'get_account_customer' or 'get_my_account_profile'. Without any usage instructions, an AI agent would have to guess based on 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action ('Get plans of a product') without any details on permissions required, rate limits, pagination, error handling, or what the return format might be. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('Get plans of a product'), which is concise but under-specified. While it avoids unnecessary words, it fails to provide essential context that would help an AI agent use the tool effectively, making it more of an under-description than true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'plans' are, how results are returned, or any behavioral aspects. For a tool with zero structured data support, the description should provide more context to be useful, but it only offers a minimal statement of purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% schema description coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate here since none are required. However, it does not clarify if parameters are implicitly handled (e.g., via context or defaults), so it slightly misses full compensation for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get plans of a product' is a tautology that essentially restates the tool name 'get_plans_of_a_product'. It specifies the verb 'get' and resource 'plans of a product', but does not distinguish this from sibling tools like 'get_product' or 'get_product_items', nor does it clarify what 'plans' means in this context (e.g., pricing plans, subscription plans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for retrieving product-related data (e.g., 'get_product', 'get_product_items', 'get_products'), but the description offers no context on when this specific tool is appropriate, such as for fetching associated plans versus general product details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create meter' implies a write operation but offers no details on permissions, side effects, error conditions, or response format. It fails to address whether creation is idempotent, what data is initialized, or how it interacts with related tools like 'report_usage'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Create meter'), which is efficient but borders on under-specification. While it avoids waste, it lacks the front-loaded detail needed for a creation tool—such as purpose or outcome—making it minimally viable rather than optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations, no output schema, and sibling tools like 'report_usage', the description is incomplete. It does not explain what a meter is, how it's used, or what the creation yields, leaving significant gaps for an agent to understand the tool's role in the system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description appropriately does not attempt to describe nonexistent parameters, avoiding redundancy. This aligns with the baseline expectation for tools without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create meter' is a tautology that merely restates the tool name without adding meaningful context. It specifies the verb 'Create' and resource 'meter', but lacks any detail about what a meter represents or what creation entails. This provides minimal differentiation from sibling tools like 'create_plan' or 'create_product' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions for creation, or relationships to sibling tools like 'get_meter', 'get_meters', or 'report_usage'. This leaves the agent with no contextual cues for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Health check' implies a read-only diagnostic operation, but the description doesn't confirm this, specify what gets checked (system, API, database), indicate authentication requirements, mention rate limits, or describe what happens when invoked. The agent must guess 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, but this represents under-specification rather than effective brevity. While technically 'front-loaded' (the entire description is the first two words), it fails to provide necessary information. The single phrase doesn't earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (no parameters, no annotations, no output schema), the description is still incomplete. A health check tool in a billing/account management context should at minimum indicate what aspect of the system is being verified. The description leaves critical questions unanswered about what the tool actually returns or verifies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for parameter gaps, and the baseline for zero parameters is 4. The description doesn't add parameter information (since there are none), but also doesn't create confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Health check' is a tautology that restates the tool name without specifying what it actually does. It doesn't identify what resource is being checked or what specific health verification is performed. While the name suggests a diagnostic operation, the description adds no meaningful clarification beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of appropriate contexts, prerequisites, or comparison to sibling tools like 'get_meters' or 'get_products' that might provide system status information. The agent receives zero usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create product' implies a mutation operation but reveals nothing about permissions, side effects, error conditions, or response format. For a creation tool with zero annotation coverage, this leaves critical behavioral traits unspecified, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, but this brevity borders on under-specification rather than efficient communication. While front-loaded, it lacks the substance needed to be truly helpful. Every word earns its place, but more words are needed to provide adequate context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It fails to explain what 'product' means, what data might be returned, or any behavioral nuances. For a creation tool in a context with multiple product-related siblings, this minimal description leaves too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate given the absence of parameters. It meets the baseline for tools without parameters by not misleading or omitting necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create product' is a tautology that merely restates the tool name without elaboration. It specifies the verb 'create' and resource 'product', but lacks any detail about what a 'product' entails in this context or how this creation differs from sibling tools like create_product_item. This minimal statement provides basic direction but fails to distinguish purpose meaningfully.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like create_product_item (for sub-items), delete_product, and get_products, the description offers no context on prerequisites, sequencing, or appropriate scenarios. The agent must infer usage from tool names alone, which is insufficient for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get meter' implies a read operation, but it doesn't specify whether this requires authentication, what data is returned (e.g., meter details, status), or any limitations like rate limits or error conditions. The description adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with zero wasted text. It is front-loaded with the core action ('Get') and resource ('meter'), making it easy to parse. Every word serves a purpose, though it may be overly minimal for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely retrieves specific data. It doesn't explain what a 'meter' is in this context, what information is returned, or any behavioral aspects. For a read operation with one parameter, more context is needed to be fully helpful to an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'meter_id' documented as a required string. The description 'Get meter' implies the parameter is used to identify a specific meter, but adds no semantic details beyond what the schema provides, such as format examples or what constitutes a valid meter_id. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get meter' is a tautology that merely restates the tool name without adding meaningful context. It specifies a verb ('Get') and resource ('meter'), but lacks any detail about what 'meter' represents or what information is retrieved. Compared to sibling tools like 'get_meters' (plural) or 'get_usage', it doesn't distinguish its specific scope or purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as needing a meter_id, or differentiate it from similar tools like 'get_meters' (which likely lists multiple meters) or 'get_usage' (which might retrieve usage data). There's no explicit or implied context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get sub-account' implies a read operation, but it doesn't disclose any behavioral traits such as authentication needs, rate limits, error handling, or what the return format might be (e.g., JSON structure). This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, 'Get sub-account', which is front-loaded and wastes no space. Every word earns its place by stating the core action and resource, making it efficient despite its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't provide enough context for an AI agent to understand the tool's behavior, return values, or how it fits with siblings. For a read operation with no structured data on outputs, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one parameter 'account_id' documented as 'Example value: '. The description adds no meaning beyond this, as it doesn't explain what 'account_id' represents (e.g., parent account ID, sub-account identifier) or provide context. With high schema coverage, the baseline is 3, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sub-account' states a verb ('Get') and resource ('sub-account'), providing a basic purpose. However, it's vague about what a 'sub-account' entails compared to siblings like 'get_accounts_customers' (plural) or 'get_my_account_profile', lacking specific differentiation. It doesn't clarify if this retrieves a single sub-account by ID or general sub-account data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. For example, it doesn't specify if 'get_accounts_customers' should be used for listing multiple sub-accounts or if this is for detailed retrieval of one. No context, exclusions, or prerequisites are mentioned, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Create', implying a mutation without details on permissions, side effects, or response format. It lacks behavioral context like whether it's idempotent, requires authentication, or has rate limits, which is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it's under-specified in content, which slightly reduces its effectiveness despite the good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'plan' is, how it relates to products, or what the creation entails, leaving significant gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable as there are no parameters to explain, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create plan of a product' states a verb ('Create') and resource ('plan of a product'), providing a basic purpose. However, it's vague about what a 'plan' entails and doesn't distinguish it from sibling tools like 'create_product' or 'get_plans_of_a_product', leaving ambiguity in scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing product, or compare it to siblings like 'create_product' or 'get_plans_of_a_product', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Create' implies a mutation, but it doesn't specify permissions, side effects, or response format. It lacks details on what happens upon creation, such as if it's irreversible or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more informative by adding context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'product item' is, how it differs from a product, or what the creation entails, leaving significant gaps for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable as there are no params to explain, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('product item of a product'), making the purpose understandable. However, it's vague about what a 'product item' entails and doesn't distinguish it from siblings like 'create_product' or 'create_plan', leaving ambiguity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether a product must exist first or how it relates to siblings like 'create_product' or 'get_product_items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get my account' implies a read-only operation, but it doesn't specify what data is returned (e.g., profile details, settings), any authentication requirements, rate limits, or error conditions, leaving significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get my account' is extremely concise—three words that directly convey the core action and resource. It's front-loaded with no unnecessary elaboration, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but inadequate. It lacks details on what 'my account' entails (e.g., profile vs. settings), return format, or behavioral context, making it incomplete for effective use despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any, earning a baseline high score for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get my account' clearly states the action (get) and resource (my account), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_account_customer' or 'get_accounts_customers', which might retrieve similar account-related data but for different scopes or entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't specify if this is for retrieving the current user's profile, as opposed to other account-related tools, or mention any prerequisites or contexts for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![bachai-usage-and-billing MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-usage-and-billing/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-usage-and-billing)

Score Badge

Copy to your README.md:

[![bachai-usage-and-billing MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-usage-and-billing/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-usage-and-billing)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bachai-usage-and-billing'

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