Skip to main content
Glama

chargebee_documentation_search

Search Chargebee documentation to find answers about subscription management, billing concepts, product features, and general documentation queries without implementation details.

Instructions

Only use this tool for general product documentation queries, NOT for implementation questions.

Do not use this tool for code generation or implementation questions. For any developer questions about implementing Chargebee functionality (like "how to update billing address", "how to create subscription", etc.), use "chargebee_code_planner" tool instead.

This tool should only be used for:

  • General product documentation queries about Chargebee's features and concepts

  • Understanding billing, payments, receivables, revenue recognition concepts

  • Learning about subscription management processes

  • Finding product feature explanations and overviews

  • Non-implementation related documentation queries

It takes the following arguments:

  • query (string): The user query to search an answer for in the Chargebee documentation.

  • language (enum): The programming language for the documentation. Check the user's application language.

  • userRequest (string): User's original request to you.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe user query to search an answer for in the Chargebee documentation.
userRequestNoUser's original request to you.
languageNoThe programming language for the documentation. Check the user's application language.

Implementation Reference

  • The core handler function that executes the tool's logic by invoking chargebeeAIClient.documentationSearch with query, language filter, and userRequest.
    const documentationSearch = async (
    	parameters: z.infer<typeof documentationSearchParameters>,
    ) => {
    	try {
    		const results = await chargebeeAIClient.documentationSearch({
    			query: parameters.query,
    			filters: {
    				language: parameters.language,
    			},
    			userRequest: parameters.userRequest,
    		});
    		return results;
    	} catch (error) {
    		if (error instanceof Error) {
    			console.error('Error searching documentation:', error.message);
    			return `Failed to search documentation: ${error.message}`;
    		}
    		console.error('Error searching documentation:', error);
    		return 'Failed to search documentation';
    	}
    };
  • Zod schema defining the tool's input parameters: query (string, required), userRequest (string, optional), language (enum of SDKs, optional).
    const documentationSearchParameters = z.object({
    	query: z.string().describe(queryParamDescription),
    	userRequest: z.string().describe(userRequestParamDescription).optional(),
    	language: z
    		.enum([
    			'node',
    			'python',
    			'curl',
    			'java',
    			'go',
    			'ruby',
    			'php',
    			'dotnet',
    		])
    		.describe(languageParamDescription)
    		.optional(),
    });
  • Tool registration object specifying the method name, name, description (prompt), parameters schema, and execute handler.
    export const documentationSearchTool = {
    	method: 'chargebee_documentation_search',
    	name: 'Chargebee Documentation Search',
    	description: documentationSearchPrompt,
    	parameters: documentationSearchParameters,
    	execute: documentationSearch,
    };
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes the tool's scope and limitations well but doesn't disclose behavioral traits like rate limits, authentication requirements, pagination, or error handling. The description doesn't contradict any annotations since none exist.

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 appropriately sized and front-loaded with critical usage guidance. However, it contains some redundancy (repeating 'NOT for implementation questions' twice) and could be more tightly structured. Most sentences earn their place by providing distinct guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description provides good contextual coverage of purpose, usage boundaries, and parameter overview. It lacks details about return values and behavioral characteristics, but the clear scope definition compensates reasonably well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description lists the parameters but adds minimal semantic value beyond what's in the schema descriptions. The baseline of 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Chargebee documentation for general product queries, distinguishing it from the sibling 'chargebee_code_planner' tool. It specifies the verb 'search' and resource 'Chargebee documentation' with explicit scope limitations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('general product documentation queries') and when not to use it ('NOT for implementation questions'), with a clear alternative named ('chargebee_code_planner'). It includes both positive use cases and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/ampcome-mcps/chargebee-mcp'

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