Enables the creation of webhook processing pipelines to receive, transform, and validate data from GitHub.
Supports the deployment and management of serverless JavaScript functions and API endpoints on the Codehooks.io platform.
Enables the creation of webhook processing pipelines to receive, transform, and validate data from Stripe.
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., "@Codehooks.io MCP Server Deploy a serverless JS function to handle new user signups."
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.
An MCP (Model Context Protocol) server that provides AI agents with database operations, serverless code deployment, and file management capabilities on the Codehooks.io platform.
Environment | Has Terminal? | Recommended Approach |
Claude Code | Yes | Use |
Cursor | Yes | Use |
Claude Desktop | No | This MCP server |
Using the Codehooks CLI directly is simpler and more flexible:
Install the CLI: npm install -g codehooks
Login: coho login
Get the AI prompt: coho prompt
Or reference the online docs: https://codehooks.io/llms.txt
The agent can then run coho commands directly in the terminal.
Use this MCP server to give the AI access to Codehooks functionality. See the Setup section below.
Related MCP server: AppsAI MCP Server
Query and update collections (including metadata) with filters and sorting
Create and manage collections
Import/export data (JSON,JSONL,CSV)
Add schemas and indexes, cap collections
Deploy JavaScript serverless functions
Upload files to cloud storage
List and browse files
Delete files
Inspect file metadata
Store key-value pairs
Retrieve one or many key-value pairs
Delete key-value pairs
Set time-to-live (TTL) for key-value pairs
View application logs
Access API documentation (local documentation for the MCP agent)
coho login
coho add-admintokenCreate a folder for your MCP server scripts:
mkdir ~/mcp-servers
cd ~/mcp-serversFor macOS/Linux - Create codehooks.sh:
#!/bin/bash
# Set PATH to include common Docker locations
export PATH="/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:$PATH"
exec docker run --rm -i \
--pull always \
-e CODEHOOKS_PROJECT_NAME=your_project_name \
-e CODEHOOKS_ADMIN_TOKEN=your_admin_token \
-e CODEHOOKS_SPACE=your_space_name \
ghcr.io/restdb/codehooks-mcp:latestMake it executable:
chmod +x ~/mcp-servers/codehooks.shFor Windows - Create codehooks.bat:
@echo off
docker run --rm -i ^
--pull always ^
-e CODEHOOKS_PROJECT_NAME=your_project_name ^
-e CODEHOOKS_ADMIN_TOKEN=your_admin_token ^
-e CODEHOOKS_SPACE=your_space_name ^
ghcr.io/restdb/codehooks-mcp:latestReplace your_project_name, your_admin_token, and your_space_name with your actual values.
Add to your claude_desktop_config.json:
macOS/Linux:
{
"mcpServers": {
"codehooks": {
"command": "/Users/username/mcp-servers/codehooks.sh"
}
}
}Windows:
{
"mcpServers": {
"codehooks": {
"command": "C:\\Users\\username\\mcp-servers\\codehooks.bat"
}
}
}Add to your ~/.cursor/mcp.json:
macOS/Linux:
{
"mcpServers": {
"codehooks": {
"command": "/Users/username/mcp-servers/codehooks.sh"
}
}
}Windows:
{
"mcpServers": {
"codehooks": {
"command": "C:\\Users\\username\\mcp-servers\\codehooks.bat"
}
}
}Replace username with your actual username.
"Build a complete survey system: create a database, deploy an API to collect responses, and add search/analytics endpoints"
"Set up a real-time inventory tracker: import my product CSV, create stock update webhooks, and build low-stock alerts"
"Build a webhook processing pipeline: receive webhooks from multiple sources, transform and validate data, then trigger automated actions"
"Build a content management system: create file upload endpoints, set up a metadata database, and deploy content delivery APIs"
"Set up automated data backups: export my collections to JSON files, store them with timestamps, and create restoration endpoints"
The AI agent would:
Create collections (surveys, responses) for data storage
Add schemas for data validation and structure
Deploy JavaScript endpoints like POST /surveys and GET /surveys/:id/analytics
Create indexes on response fields for fast searching and analytics
The AI agent would:
Import your CSV to populate the products collection
Deploy webhook handlers for POST /inventory/update and GET /inventory/low-stock
Set up key-value storage for alert thresholds and settings
Create indexes on SKU and stock levels for real-time queries
The AI agent would:
Deploy webhook receivers like POST /webhooks/stripe and POST /webhooks/github
Create collections for webhook_logs, processed_events, and failed_events
Set up data transformation rules and validation schemas for each webhook source
Use key-value store for rate limiting and duplicate detection with TTL
Deploy action triggers that send emails, update databases, or call other APIs based on webhook data
The AI agent would:
Create collections for content, media, and users
Deploy file upload endpoints with POST /upload and GET /content/:id
Upload and manage static files for content delivery
Store metadata linking files to content records with search indexes
The AI agent would:
Export collections to JSON format with timestamps
Upload backup files to cloud storage automatically
Deploy restoration APIs like GET /backups and POST /restore/:backup-id
Store backup metadata in key-value store for tracking and management
Each example demonstrates how multiple MCP tools work together to create complete, production-ready systems through natural conversation with your AI agent.
We thank the following individuals for responsible disclosure and helping improve the security of this project:
Liran Tal – Reported a command injection vulnerability in the query_collection tool (May 2025)
This project is licensed under the MIT License.
Add a JSON schema to a collection. Provide the schema content as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | JSON schema content as a string (will be written to temporary file for CLI) | |
| collection | Yes | Collection name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It does not mention whether adding a schema overwrites existing schemas, validates content, or requires specific permissions. The mention of a temporary file for CLI is a minor behavioural hint but 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?
Two concise sentences that convey the core functionality without unnecessary elaboration. Every word earns its place, making it easy for an agent 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, output schema, and moderate complexity (two required parameters), the description is minimally adequate. It fails to mention return values, error handling, or whether the schema replaces or appends, leaving gaps for an 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?
Input schema coverage is 100% for both parameters. The description adds 'JSON string' context, reinforcing the schema's description. This meets the baseline expectation but does not provide additional semantic value beyond what the schema already conveys.
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 ('Add a JSON schema to a collection') and what is required ('Provide the schema content as a JSON string'). It effectively distinguishes this tool from its siblings like 'remove_schema' and collection operations.
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 'create_collection', 'update_collection', or 'remove_schema'. The description lacks any context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cap a collection
| Name | Required | Description | Default |
|---|---|---|---|
| cap | Yes | Maximum number of documents | |
| collection | Yes | Collection name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., whether the action is destructive, reversible, or what happens to existing documents beyond the cap). This lack of transparency could lead to unexpected side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At six words, the description is extremely concise but at the expense of necessary context. It fails to clarify important behavioral aspects, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description should compensate by explaining return values, side effects, and prerequisites. It does not, leaving significant gaps 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 input schema has 100% coverage with clear descriptions for both parameters ('Collection name' and 'Maximum number of documents'). The description does not add extra meaning beyond the schema, so baseline 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 uses the verb 'Cap' which might be interpreted as setting a maximum limit, and the input schema confirms with a 'Maximum number of documents' parameter. However, 'cap' is somewhat jargon and not explicitly defined, making the purpose moderately clear but not universally understandable.
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 'uncap_collection'. Without context, an agent cannot differentiate the use case for capping a collection from other collection operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show collections for space. Lists all collections available in the current space.
| Name | Required | Description | Default |
|---|---|---|---|
| sys | No | Show system collections | |
| json | No | JSON output format | |
| project | No | Project name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Show', 'Lists') but does not explicitly state no modifications occur. With no annotations, the agent must infer safety. A direct statement would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The purpose is front-loaded and every sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple listing tool but lacks details on return format (e.g., list of names or full objects) and does not mention pagination or limits, which could affect agent expectations.
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?
Input schema covers 100% of parameters with brief descriptions. The tool description adds no additional meaning beyond what is already in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists collections in the current space (verb+resource). However, it does not differentiate from sibling tools like query_collection, which might also list collections with filtering.
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 query_collection or other listing tools. The context 'current space' is implied but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Name of collection to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'Create a new collection', implying a write operation, but gives no details on side effects, permissions, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and detail. It is too minimal to be considered 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?
Despite having only one parameter and no output schema, the description is incomplete. It does not explain what a collection is, what happens upon success, or how it fits with sibling tools like 'add_schema' or 'query_collection'.
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% coverage for the single parameter 'collection', with a clear description 'Name of collection to create'. The tool description adds no additional meaning beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new collection' states a verb and resource, making it clear that this tool creates a collection. However, it lacks specificity about what a collection is in this context, and does not differentiate from sibling tools like 'collection' or 'add_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?
The description provides no guidance on when to use this tool versus alternatives such as 'cap_collection', 'drop_collection', or 'query_collection'. It does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add field(s) to a query index
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Field(s) to add to query index | |
| collection | Yes | Collection name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the basic action. It does not disclose whether the index creation is immediate, idempotent, or requires special permissions. Behavior beyond the action is opaque.
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 phrase, making it concise. However, it lacks structure—no front-loading of key information, and it does not separate purpose from usage details. It is functional but not well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters and no output schema, the description is minimal. It does not explain return values, side effects, or the effect on existing indexes. For a mutation tool, this leaves significant gaps.
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 explains the parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline for this dimension.
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 'Add field(s) to a query index' clearly states the verb and resource, distinguishing it from sibling 'drop_index'. However, it could be more specific about the scope (e.g., 'Create a new index on a collection with specified fields').
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 'query_collection' or 'add_schema'. There is no context about prerequisites, performance implications, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy JavaScript code to Codehooks.io project.
MINIMAL WORKING EXAMPLE:
import { app } from 'codehooks-js';
app.get('/hello', (req, res) => {
res.json({ message: 'Hello, world!' });
});
// MANDATORY: bind to serverless runtime
export default app.init();INSTANT CRUD BACKEND:
import { app } from 'codehooks-js';
// Creates complete CRUD API for any collection (no schema required)
app.crudlify();
export default app.init();KEY REQUIREMENTS:
Always import from 'codehooks-js'
Always end with export default app.init();
Use app.get(), app.post(), app.put(), app.delete() for routes
For database: const conn = await Datastore.open(); conn.insertOne(collection, data);
Use app.crudlify() to create complete CRUD backend with no schema required
Package.json will be auto-generated if not provided
DOCUMENTATION:
Use 'docs' tool for more information
Online ChatGPT prompt: https://codehooks.io/docs/chatgpt-backend-api-prompt
Online Workflow API: https://codehooks.io/docs/workflow-api
LLM-optimized docs: https://codehooks.io/llms.txt and https://codehooks.io/llms-full.txt
Note: Codehooks.io has CORS built-in by default, so no additional CORS middleware is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Output JSON format | |
| main | No | Application main file (defaults to 'index') | |
| files | Yes | Array of files to deploy | |
| spaceId | No | Space ID | dev |
| projectId | No | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions auto-generation of package.json and built-in CORS, but does not disclose potential side effects like overwriting existing code or permission requirements. This is adequate but not comprehensive.
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 relatively long but well-structured with clear sections, code examples, and links. The first sentence states the purpose. Every part adds value, though some details could be condensed. Justified 4.
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?
Considering the tool's complexity (deploying code files) and the absence of output schema or annotations, the description provides comprehensive context: examples, requirements, and documentation links. It covers what the agent needs to invoke the tool 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%, with each parameter described. The description adds value through examples and requirements (e.g., 'index.js' path, 'dev' space default), but does not significantly extend beyond the schema's own descriptions. Baseline 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 explicitly states 'Deploy JavaScript code to Codehooks.io project.' This is a specific verb-resource pair, and the examples further clarify. No sibling tool duplicates this purpose.
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 key requirements, minimal working examples, and instructions. It implicitly guides when to use this tool (to deploy code). However, it does not explicitly state when not to use it or list alternatives, though no close siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive Codehooks.io documentation and examples. Includes complete ChatGPT prompt, setup instructions, code examples, and API reference.
| 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 the full burden of disclosing behavioral traits. It implicitly indicates a read operation ('Get') and summarizes contents, but does not explicitly state that it is safe, has no side effects, or mention any authentication or rate limits. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main purpose, and every sentence adds value. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is largely complete, listing the types of documentation returned. However, it omits the format (e.g., plain text, markdown, PDF) and any size limitations, which would improve contextual completeness.
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 no parameters and the input schema is an empty object, so schema coverage is 100%. The description adds meaning by enumerating the documentation sections included (ChatGPT prompt, setup instructions, code examples, API reference), which goes beyond the empty schema. Baseline for zero parameters is 4, and the description meets it.
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 that the tool retrieves 'comprehensive Codehooks.io documentation and examples,' using a specific verb and resource. It distinguishes itself from sibling tools, which are all CRUD, file, or index operations, by being the only documentation tool.
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 documentation is needed but provides no explicit guidance on when to use this tool versus alternatives. There are no other documentation tools among siblings, so the lack of exclusion criteria is acceptable but still leaves room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Name of collection to drop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not state that deletion is irreversible or that it removes all documents in the collection. For a destructive operation, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient, though could benefit from slight expansion.
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 simple tool with one parameter and no output schema, the description is minimally adequate. However, missing behavioral details (e.g., irreversibility) and usage context make it less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter with description). The description adds no extra meaning beyond what the schema already provides, so baseline score of 3.
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 'Delete a collection' clearly states the verb (delete) and resource (collection), distinguishing it from sibling tools like create_collection, cap_collection, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cap_collection or drop_index. No prerequisites (e.g., collection must exist) or consequences mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove field(s) from a query index
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Field(s) to remove from query index | |
| collection | Yes | Collection name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full burden. It only states the action without disclosing side effects (e.g., is the operation irreversible? Does it affect existing queries? No details on performance or safety).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, perfectly front-loaded with the essential action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple two-parameter tool with no output schema. Description covers the basics but omits behavioral context (e.g., confirmation, error cases). Adequate for a straightforward operation but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions), so the description adds marginal value. It correctly implies the 'index' parameter holds field(s) to remove, but does not elaborate beyond schema definitions.
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 'Remove field(s) from a query index' specifies the verb (remove) and resource (query index), clearly distinguishing from siblings like create_index or drop_collection. Lacks explicit contrast but the name and description make the purpose obvious.
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 (e.g., drop_collection to remove entire collection). No prerequisites or conditions provided, leaving the agent to infer from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export data from collection. If no filepath specified, returns the exported content directly. If filepath specified, saves to file inside Docker container.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | Export to CSV format | |
| jsonl | No | Export to JSONL format | |
| filepath | No | File to save export data (optional, will return content if not specified) | |
| collection | Yes | Collection to export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two behavioral paths based on filepath (return vs save), which is useful. However, it omits details like whether saving overwrites, what is returned when filepath is specified, and any side effects. Without annotations, the description carries full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the main action. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core behavior but lacks details on output format (when returned), error handling, and behavior when multiple format flags are set. Given no output schema and no annotations, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters have descriptions. The description adds value by explaining the conditional behavior of filepath (return vs save), which is beyond what the schema provides. However, it does not elaborate on csv and jsonl beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Export data from collection' with a specific verb and resource, and distinguishes two modes of operation (return vs save to file). This sets it apart from sibling tools like 'import' or 'query_collection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'query_collection', or any prerequisites or exclusions. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file from server
| Name | Required | Description | Default |
|---|---|---|---|
| match | No | Delete multiple files that match regular expression to a file path. Use this or 'filename'. | |
| dryrun | No | Output files to delete without performing the action | |
| filename | No | Delete file with match on absolute path/filename. Use this or 'match'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to mention irreversibility of deletion, ability to delete multiple files with 'match', or the effect of 'dryrun'. Behavioral context 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?
Single sentence, concise, no unnecessary words. Efficiently communicates core action.
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 three parameters with diverse behaviors (filename vs match, dryrun), the description is too sparse. Lacks explanation of parameter interactions and safety warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, covering all three parameters. Description adds no additional meaning beyond the schema, meeting baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a file from server', specifying action and resource. Distinguishable from siblings like file_list or file_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like file_list or file_upload. Lacks context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files from server
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to list files from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. The one-line description adds no information beyond the tool name, failing to mention output format, error behavior, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 4 words, front-loading the core purpose. While it lacks structure, it is appropriately terse for a simple list operation and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description does not explain default behavior when 'path' is omitted or what the returned list contains (e.g., names, metadata). This lack of context makes it incomplete for an 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 already has 100% description coverage for the 'path' parameter. The tool description does not add any additional meaning or context beyond what is in the schema, so it meets the baseline of 3.
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 ('files'), and specifies 'from server', which distinguishes it from sibling tools like file_delete and file_upload. However, it does not elaborate on what information is listed or the scope.
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 file_list versus alternatives. There is no mention of prerequisites, conditions, or exclusion cases, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload files to server
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target path/filename on server | |
| content | Yes | File content as text or base64 | |
| encoding | No | Content encoding type | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose critical behaviors such as overwrite policies, request size limits, or error handling. The bare description 'Upload files to server' leaves the agent uninformed about consequences of invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous text. However, its brevity sacrifices important details, such as clarifying the encoding parameter or the nature of the target path. It is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 3 parameters, the description should cover usage context and return behavior. It only states the basic action, leaving gaps about success indicators, error messages, and whether the upload is synchronous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a functional description. The tool description adds no extra meaning beyond stating the overall action. For a 3-parameter tool with full schema coverage, baseline 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 'Upload files to server' states a clear verb and resource, distinguishing it from sibling tools like file_list and file_delete. However, it lacks details about supported content types (text or base64) and the upload mechanism.
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 (e.g., kv_set for key-value storage) or on prerequisites like file size limits or authentication. The description implies use for file uploads but offers no 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.
Import data from file or content. Provide either 'filepath' (for files inside Docker container) or 'content' (JSON/CSV data as string).
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | File content to import as JSON or CSV data (optional if filepath is provided) | |
| encoding | No | File encoding | |
| filepath | No | File path to import from (optional if content is provided) | |
| separator | No | CSV separator character | |
| collection | Yes | Collection to import into |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as whether import overwrites existing data, what happens on failure, or authorization requirements. This is a significant gap 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?
Two sentences, front-loaded with primary purpose, no redundant information. Every sentence is efficient and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main input methods but does not explain optional parameters like separator and encoding, nor return value or success/failure indications. With no output schema and 5 parameters, more detail is warranted.
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 has 100% description coverage, but description adds context: clarifies that 'filepath' is for files inside Docker container and 'content' is JSON/CSV string, which goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool imports data from file or content, distinguishing it from sibling 'export' which does the opposite, and 'file_upload' which handles file transfer not data import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions providing either 'filepath' or 'content', implying when to use each, but lacks guidance on when to prefer this tool over alternatives like direct API calls or file_upload, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete key-value pair in a space.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to delete | |
| json | No | Output info as JSON (not table) | |
| keyspace | No | Keyspace to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Delete' without mentioning irreversibility, permissions, or side effects, leaving significant gaps.
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 concise sentence with no wasted words, placed front and center.
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 output schema and three parameters (one required), the description lacks details on default keyspace, output behavior, and whether deletion is immediate or cascading. Incomplete for safe agent 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?
All parameters are described in the input schema (100% coverage), so the description adds no extra meaning beyond what the schema provides. Baseline score 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 verb 'Delete' and the resource 'key-value pair in a space,' distinguishing it from sibling tools like kv_get and kv_set. However, 'space' is not explicitly defined, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The agent must infer usage context 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.
Retrieve key-value pair(s) from a space. Supports pattern matching with wildcards.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Key to match, or key* to fetch list | * |
| text | No | Output info as text line | |
| keyspace | No | Keyspace to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose read-only nature, effects, and limitations. It only states retrieval and pattern matching, omitting behavior for missing keys, result format, or resource consumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, but lacking details on pagination, multiple matches, or error handling. Without output schema, description should clarify return format.
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 description adds no new meaning beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves key-value pairs and supports wildcard pattern matching, distinguishing it from sibling tools like kv_set and kv_del.
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 (e.g., kv_del for deletion). Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set key-value pair in a space with optional TTL and keyspace.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to set | |
| ttl | No | Time to live in millis for value | |
| val | Yes | Value to set | |
| json | No | Output info as JSON (not table) | |
| keyspace | No | Keyspace to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose side effects (e.g., overwriting existing keys), atomicity, or error handling. Only states basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 parameters and no output schema, description adds minimal context. No info on return values, ordering, or behavior beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add additional semantic meaning beyond what schema already specifies for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (Set), resource (key-value pair), and optional features (TTL, keyspace). Distinguishes from siblings like kv_del and kv_get.
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 vs alternatives (e.g., kv_get for reading, kv_del for deletion). Context of use is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show system logs for a space with filtering and follow options.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | Chop log to n lines | |
| follow | No | Keep log stream open | |
| context | No | Filter log on: jobhooks, queuehooks, routehooks, datahooks, auth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It mentions 'show' implying a read operation but does not disclose whether follow keeps a stream open indefinitely, authentication requirements, or any side effects. Minimal behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It captures the main action concisely, though omitting minor details like 'for a space' might be acceptable depending on 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 has 3 parameters and no output schema, the description should explain what the output contains, pagination, or how follow behaves. It lacks this, leaving the agent underinformed about the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds generic context ('filtering and follow options') but does not provide meaningful semantic enrichment beyond what the schema descriptions already offer.
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 retrieves system logs for a space, with filtering and follow options. It is specific but does not differentiate from siblings; however, no sibling appears to offer log functionality.
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, nor any prerequisites or exclusions. The description simply states what it does without context for when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query data from a collection. Supports URL-style, regex, and MongoDB-style JSON queries with comparison operators. Can also query system collections like '_hooks' which contains deployment metadata including available API endpoints. Using delete, update or replace is very powerful but also dangerous, so use with caution.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | Output data in CSV format | |
| end | No | End value for index scan | |
| sort | No | Comma separated list of fields to sort by. Use '_id' to sort by creation time | |
| count | No | Count query results | |
| jsonl | No | Output data in JSONL format | |
| limit | No | Limit query result. Use limit=1 and reverse to get latest deployment from _hooks collection | |
| query | No | Query expression. Supports multiple formats: URL-style ('name=Polly&type=Parrot'), regex ('name=/^po/'), or MongoDB-style JSON ('{"name": "Polly", "age": {"$gt": 5}}' for complex queries with operators like $gt, $lt, $gte, $lte, $ne, $in, $nin, $exists, $regex). To get the latest deployment info with API endpoints, use: collection='_hooks', limit=1, reverse=true (check the routehooks property for the available API endpoints) | |
| start | No | Start value for index scan | |
| delete | No | Delete all items from query result | |
| fields | No | Comma separated list of fields to include | |
| offset | No | Skip items before returning data in query result | |
| update | No | Patch all items from query result with JSON string '{...}' | |
| enqueue | No | Add query result to queue topic | |
| replace | No | Replace all items from query result with JSON string '{...}' | |
| reverse | No | Scan index in reverse order. Use with sort='_id' to get newest records first | |
| useindex | No | Use an indexed field to scan data in query | |
| collection | Yes | Collection name. Use '_hooks' to query deployment metadata and discover available API endpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It warns about dangerous operations (delete, update, replace) and explains query formats with examples. However, it omits details on error handling, side effects of non-destructive operations, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose. The warning about destructive ops is useful. It could be slightly more structured (e.g., separate sentences for distinct points), but overall efficient.
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 (17 params, destructive actions, system collections), the description covers query formats, one use case (_hooks), and a warning. It lacks mention of pagination, error states, or full capability overview, but schema descriptions fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The main description adds minimal parameter semantics beyond the schema (e.g., hints on using limit/reverse for latest data). Most parameter details are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Query data from a collection' and lists supported query formats (URL-style, regex, MongoDB-style JSON). This distinctively identifies the tool's function against siblings like 'create_collection' or 'drop_collection'.
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 lacks explicit guidance on when to use this tool vs alternatives. It only hints at querying system collections for deployment metadata but does not compare with other tools like 'docs' or provide scenarios for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove JSON schema from a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection to remove schema from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without discussing effects like whether the schema must exist, reversibility, or impact on 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?
A single sentence with no wasted words, achieving conciseness. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is adequate but lacks details on return values or side effects, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds 'JSON schema' context but repeats the schema's parameter description, providing marginal additional 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 'Remove JSON schema from a collection' is clear with a specific verb (Remove), resource (JSON schema), and target (collection). It effectively distinguishes from sibling tools like add_schema and create_collection.
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, nor any prerequisites or conditions for removal. The description lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove cap from a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection to remove cap from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action 'remove cap' without mentioning side effects, authentication needs, reversibility, or result behavior. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the action without waste. However, it may be too minimal, lacking detail that could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally complete. However, the term 'cap' is not explained, leaving ambiguity about what exactly is being removed. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The parameter description 'Collection to remove cap from' adds meaning beyond the parameter name, but the tool description itself does not provide additional 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 'Remove cap from a collection' uses a specific verb ('Remove') and resource ('cap from a collection') clearly defining the tool's action. It implicitly distinguishes from sibling 'cap_collection' which does the opposite.
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. There is no mention of prerequisites, when to avoid, or comparison with 'cap_collection' or other sibling tools.
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.0add_schemacap_collectioncollectioncreate_collectioncreate_indexdeploy_codedocsdrop_collectiondrop_indexexportfile_deletefile_listfile_uploadimportkv_delkv_getkv_setlogsquery_collectionremove_schemauncap_collectionEach tool targets a distinct operation or resource: collections, schemas, indexes, queries, key-value store, files, import/export, logs, etc. Even similar-sounding tools like 'collection' (list) and 'create_collection' are clearly differentiated by their descriptions.
All tool names use snake_case consistently and follow a verb_noun pattern (e.g., 'add_schema', 'create_collection', 'file_upload', 'kv_set'). Exceptions like 'collection', 'docs', and 'logs' are short nouns for retrieval, which is a common and predictable convention.
With 21 tools, this is slightly above the typical 3-15 range for MCP servers, but the number is justified by the comprehensive set of operations (database, files, KV store, logs, etc.). The tools are well-scoped and each serves a clear purpose.
The tool set covers full lifecycle operations for collections (create, list, drop, cap, uncap), schemas (add, remove), indexes (create, drop), queries, key-value store (set, get, del), files (upload, list, delete), import/export, deployment, logs, and documentation. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The agent-native cloud: database, functions, AI, storage, computers. 50 tools, one API key.
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Managed database, auth, file storage, email, analytics, and deployment for coding agents.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RestDB/codehooks-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
