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., "@Databar MCP Server Get me David Abaev's LinkedIn profile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants like Claude to interact with Databar.ai's data enrichment API. Discover, configure, and run data enrichments across hundreds of data providers using natural language.
Smart Enrichment Discovery — Search and filter enrichments by keyword or category
Natural Language Interface — Ask "get David's LinkedIn profile" and the right enrichment runs automatically
Bulk Operations — Enrich many records in a single call with bulk enrichment and bulk waterfall support
Table Management — Create tables, manage columns, insert/update/upsert rows
Waterfall Support — Try multiple data providers sequentially until one succeeds
Async Handling — Automatic polling for results with no manual intervention
Intelligent Caching — 24-hour result cache reduces API calls and costs
Error Handling — Retries with exponential backoff and clear error messages
Related MCP server: Prospeo MCP Server
Node.js 18+
A Databar.ai API key (get one here)
git clone https://github.com/databar-ai/databar-mcp-server.git
cd databar-mcp-server
npm install
npm run buildEdit your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"databar": {
"command": "node",
"args": ["/absolute/path/to/databar-mcp-server/dist/index.js"],
"env": {
"DATABAR_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop. Verify by asking: "What Databar tools do you have access to?"
"Get me David Abaev's LinkedIn profile"
Claude searches for LinkedIn enrichments, picks the right one, runs it, and returns the profile data.
"Verify the email david@databar.ai"
"Find the email for John Smith at Google"
Runs a waterfall that tries multiple providers until one returns a result.
"Enrich these 10 emails with company data: [list]"
Uses bulk enrichment to process all records in a single API call.
"List my tables"
"Create 5 rows in table abc-123 with columns name and email"
"Get the columns for table abc-123"
Tool | Description |
| Search enrichments by keyword or category |
| Get parameters, pricing, and response fields for an enrichment |
| Run a single enrichment (with auto-polling and caching) |
| Run an enrichment on multiple inputs at once |
Tool | Description |
| Search available waterfall enrichments |
| Run a waterfall (tries providers sequentially) |
| Run a waterfall on multiple inputs at once |
Tool | Description |
| Create a new empty table |
| List all tables in your workspace |
| Get column schema for a table |
| Get rows with pagination |
| List enrichments configured on a table |
| Add an enrichment to a table with column mapping |
| Trigger an enrichment on all rows in a table |
Tool | Description |
| Insert up to 50 rows with deduplication options |
| Update fields on existing rows by ID |
| Insert or update rows based on a matching key |
Tool | Description |
| Get credit balance and account info |
All settings are configurable via environment variables:
Variable | Default | Description |
| (required) | Your Databar API key |
|
| API base URL |
|
| Result cache TTL in hours |
|
| Max polling attempts for async tasks |
|
| Polling interval in ms |
Server sends a run request to the Databar API
API returns a task_id
Server automatically polls /v1/tasks/{task_id} every 2 seconds
When status is completed, results are returned
If data has expired (1-hour retention), gone status is handled gracefully
Results are cached for 24 hours by default
Cache key: enrichment ID + serialized params
Cached results don't consume credits
Use skip_cache: true to force fresh data
Enrichments are automatically categorized (People, Company, Email, Phone, Social, Financial, Verification) to help the AI assistant pick the right tool.
npm run dev # Run with tsx (hot reload)
npm run build # Compile TypeScript
npm start # Run compiled outputdatabar-mcp-server/
├── src/
│ ├── index.ts # MCP server entry point & tool handlers
│ ├── databar-client.ts # Databar API client with polling
│ ├── cache.ts # In-memory cache with TTL
│ ├── types.ts # TypeScript type definitions
│ └── utils.ts # Helpers & categorization
├── dist/ # Compiled output (generated)
├── package.json
├── tsconfig.json
└── .gitignoreProblem | Solution |
Server not connecting | Verify API key, rebuild ( |
"No enrichments found" | Try a broader search query; list cache refreshes every 5 minutes |
"Task timed out" | Some enrichments take longer; increase |
"Task data has expired" | Data is stored for 1 hour only; re-run the enrichment |
"Invalid API key" | Check |
MIT
Add an enrichment to a table with a parameter-to-column mapping.
IMPORTANT — mapping format: Each key is an enrichment parameter name. Each value is one of: • { "type": "mapping", "value": "" } — read value from a table column per row. Use the human-readable column name (e.g. "email"). The server accepts column names directly. • { "type": "simple", "value": "" } — pass the same hardcoded value for every row. IMPORTANT: simple values can embed column references using {column_internal_name} syntax (e.g. "Find the industry of {column1}"). The internal_name for each column is shown by get_table_columns. At runtime, these placeholders are replaced with actual column values per row. You can also use human-readable column names (e.g. {Company Website}) — the server will auto-resolve them to internal names. Use {?column_name} to mark a column reference as optional (row won't fail if the column is empty).
WORKFLOW:
Call get_enrichment_details to see the parameter names.
Call get_table_columns to see available column names and their internal_names.
Build the mapping using column names (not UUIDs). For text/textarea parameters that should incorporate column data, use "simple" type with {column_internal_name} placeholders in the value.
The returned enrichment_id from this call is the TABLE-ENRICHMENT id — use it with run_table_enrichment (NOT the original enrichment_id).
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| enrichment_id | Yes | The enrichment ID to add (from search_enrichments or get_enrichment_details) | |
| mapping | Yes | Parameter-to-column mapping. Keys = enrichment param names. Values = { type: "mapping", value: "column-name" } or { type: "simple", value: "static-value" }. Simple values can embed {column_internal_name} placeholders (e.g. "Research {column1}") that are resolved per row at runtime. You can use human-readable column names in placeholders — the server resolves them. | |
| launch_strategy | No | When to trigger: 'run_on_click' (manual) or 'run_on_update' (auto on row change). Default: 'run_on_click'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently explains the mapping types, how simple values embed column references using {column_internal_name} syntax, optional references with {?column_name}, and that the returned id is a table-enrichment id. It lacks explicit statements on destructive behavior or error handling, but overall is highly transparent.
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 fairly long but well-structured with bold headers for important notes and a numbered workflow. Every sentence adds value. Minor redundancy could be trimmed (e.g., repeating column reference info), but overall it's justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is comprehensive: it covers mapping format, workflow, references to related tools (get_enrichment_details, get_table_columns, run_table_enrichment), and explains the returned id. Missing details on error handling or default behavior for missing columns, but still very complete for this complexity level.
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 the baseline is 3. However, the description adds substantial meaning beyond the schema, especially for the mapping parameter, explaining the two value types, column reference syntax, and the workflow. It also clarifies that enrichment_id is for the enrichment to add, and the launch_strategy enum values.
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 'Add an enrichment to a table with a parameter-to-column mapping,' providing a specific verb, resource, and scope. It also distinguishes from sibling tools by referencing the enrichment workflow and pointing to run_table_enrichment.
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 gives an explicit step-by-step workflow (call get_enrichment_details, get_table_columns, build mapping) and explains when to use this tool versus alternatives (e.g., the returned enrichment_id is for run_table_enrichment, not the original). It also provides detailed mapping format guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an exporter (CRM/destination) to a table with a parameter-to-column mapping.
IMPORTANT — mapping format: Each key is an exporter parameter name. Each value is one of: • { "type": "mapping", "value": "" } — read value from a table column per row. Use the human-readable column name (e.g. "email"). The server accepts column names directly. • { "type": "simple", "value": "" } — pass the same hardcoded value for every row.
WORKFLOW:
Call get_exporter_details to see the parameter names.
Call get_table_columns to see available column names.
Build the mapping using column names (not UUIDs).
The returned exporter_id from this call is the TABLE-EXPORTER id — use it with run_table_exporter (NOT the original exporter_id).
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| exporter_id | Yes | The exporter ID to add (from search_exporters or get_exporter_details) | |
| mapping | Yes | Parameter-to-column mapping. Keys = exporter param names. Values = { type: "mapping", value: "column-name" } or { type: "simple", value: "static-value" } | |
| launch_strategy | No | When to trigger: 'run_on_click' (manual) or 'run_on_update' (auto on row change). Default: 'run_on_click'. | |
| authorization | No | ID of the API key / OAuth connection to use. Required for exporters that need user authorization. If omitted, the system auto-selects the first available key. | |
| custom_body_template | No | Custom JSON body template. Column values are referenced via {column_internal_name} placeholders. When provided, mapping is ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses mapping format, column names vs UUIDs, custom_body_template overriding mapping, and authorization auto-select. Missing side effects or reversibility, but covers core behavior well.
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?
Description is well-structured with an 'IMPORTANT' section and workflow list. It is front-loaded but could be slightly more concise; 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 6 params and no output schema, description explains mapping and workflow well. Lacks error handling and return value details, but enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value: explains mapping format in detail, clarifies that column names are human-readable, specifies authorization ID type, and notes that custom_body_template uses internal column names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add an exporter (CRM/destination) to a table' with a specific verb and resource. It distinguishes from siblings like add_table_enrichment and add_table_waterfall by focusing on exporters.
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?
Explicit workflow: call get_exporter_details, then get_table_columns, then build mapping. Also notes that returned exporter_id is for run_table_exporter, not the original. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a waterfall to a table. A waterfall tries multiple data providers in sequence until one returns a result.
WORKFLOW:
Call search_waterfalls to find the right waterfall (e.g. "email_getter", "person_getter").
Note the waterfall identifier, available_enrichments (provider IDs), and input_params.
Call get_table_columns to see available column names.
Build the mapping: keys are waterfall param names, values are column names.
The returned id is the TABLE-WATERFALL id — use it with run_table_enrichment to trigger a run.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| waterfall_identifier | Yes | The waterfall identifier (e.g. "email_getter"). Get from search_waterfalls. | |
| enrichments | Yes | List of enrichment (provider) IDs to use in the waterfall cascade. Get from search_waterfalls available_enrichments. | |
| mapping | Yes | Maps waterfall param names to table column names. Keys = param names from waterfall input_params. Values = column names from get_table_columns. | |
| email_verifier | No | Optional enrichment ID for email verification (only for email waterfalls with is_email_verifying=true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It explains the waterfall behavior (tries providers in sequence) and the nature of the returned id (table-waterfall id, not a run). It does not mention error handling or side effects, but the core behavioral traits are covered. Score reduced slightly for missing potential failure modes.
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?
Description includes a numbered workflow block that is useful but somewhat lengthy. It is well-structured with clear steps. Could be slightly more concise, but every sentence 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?
Given no output schema, description explains the return value (table-waterfall id). It also covers the full workflow from search to run, making the tool self-contained. Sibling tools are numerous, but the description provides enough context to differentiate and use 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 coverage is 100%, but description adds significant value beyond schema: it explicitly tells where to obtain each parameter (e.g., enrichments from search_waterfalls, mapping from get_table_columns). This context is crucial for correct usage and is not present in the schema alone.
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 'Add a waterfall to a table' and explains that a waterfall tries multiple providers in sequence. It distinguishes from siblings by detailing a unique workflow involving search_waterfalls and get_table_columns, which are not required for similar tools like add_table_enrichment.
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?
Explicit workflow steps are provided (1-5), including prerequisites and post-conditions. It guides when to use this tool (after search_waterfalls and get_table_columns) and what to do with the returned id (use with run_table_enrichment). No confusion with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new column to an existing table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| name | Yes | Column display name | |
| type | No | Column type (default: 'text') | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects (e.g., default values, nullable restrictions), permissions required, or whether the operation is reversible.
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. However, for a mutation tool, it may be too brief, lacking necessary behavioral context. Front-loading is acceptable but could benefit from additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies table schema (a potentially impactful operation), with no output schema or annotations, the description is incomplete. It does not explain return values, error scenarios, or permissions, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines parameters clearly. The description adds no further meaning beyond what the schema provides, such as explaining the 'type' parameter options or naming constraints.
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 'Add a new column to an existing table,' specifying the verb (add), the resource (column), and the context (existing table). This distinguishes it from sibling tools like 'delete_column' or 'rename_column'.
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 'rename_column', 'delete_column', or other table-modifying tools. It lacks prerequisites or context about the table state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new folder to organize tables in your workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Folder name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal. Does not disclose behaviors like error handling on duplicate names, limits, or effects on existing 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?
Single clear sentence with no waste. Appropriate for simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 param and no output schema, description is minimal but adequate. Could mention return value or behavior on duplicate names.
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% (1 param with description 'Folder name'). Description adds no extra meaning beyond schema. Baseline 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?
Description clearly states verb 'Create', resource 'folder', and purpose 'to organize tables in your workspace'. It distinguishes from siblings like rename_folder and delete_folder.
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 using the root folder or other tools. No explicit context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert new rows into a table (max 100 per request). To add new columns to an existing table, set options.allow_new_columns to true — any column name in fields that does not exist yet will be auto-created as a text column.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| rows | Yes | Array of rows to insert (max 100). Each row has a fields object keyed by column name. | |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the burden. It discloses the 100-row limit and column auto-creation behavior, but omits common traits like error handling (e.g., invalid table_uuid), atomicity, idempotency, and permission requirements. More details are needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loads the primary action and limit. Every word adds value; no fluff or repetition. It efficiently conveys the core functionality and a key option.
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 absence of an output schema, the description should mention what is returned (e.g., success status or row IDs). It also lacks error scenarios and prerequisites (e.g., table must exist). It covers the main insertion mechanism but misses completeness for a well-rounded understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema for 'rows' (max 100) and 'options.allow_new_columns' (auto-creates text columns). However, it does not explain 'options.dedupe' (undocumented in schema) or the structure of 'fields' beyond key-value pairs. Schema coverage is 67%, so moderate compensation is provided but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Insert new rows into a table' with a max limit of 100, which distinguishes it from sibling tools like 'delete_rows' or 'upsert_rows'. The verb 'insert' and resource 'rows' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use 'options.allow_new_columns' to auto-create columns, noting it's the only API method for adding columns. However, it lacks explicit guidance on when not to use this tool (e.g., for updates, prefer 'patch_rows' or 'upsert_rows') and does not compare to alternatives like 'create_column'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new table in your Databar workspace. Optionally specify a name, column names, and number of empty rows. By default creates columns column1/column2/column3 and 0 rows.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Table name (default: "New empty table") | |
| columns | No | Column names. Default: ["column1","column2","column3"]. Pass empty array [] to create a table with no columns. | |
| rows | No | Number of empty rows to create (default: 0) |
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 creation and defaults but does not disclose whether it overwrites existing tables, requires specific permissions, or what the return value is. For a mutation tool without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Front-loaded with the primary action and quickly covers optional parameters and defaults.
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 3 optional parameters, no output schema, and many sibling tools, the description covers basic creation but lacks details on behavior (e.g., duplicate names, column uniqueness). Adequate 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%, and the description restates defaults and parameter options. It adds minimal value beyond the schema (e.g., default column names). 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 clearly states the action ('Create a new table') and specifies the resource ('your Databar workspace'). It outlines optional parameters and defaults, distinguishing it from sibling tools like create_column or delete_table.
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 create_column or upsert_rows. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a column from a table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| column_id | Yes | The UUID of the column to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to disclose any behavioral details such as irreversibility, side effects, or required permissions for this destructive 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?
Highly concise single sentence, but sacrifices necessary detail for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks essential context about return values, error conditions, and cascade effects; with no output schema or annotations, the description should provide more behavioral information.
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 clear descriptions for both parameters; the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (a column from a table), distinguishing it from sibling tools that delete rows or tables.
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 delete_table or rename_column, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a folder. Tables inside the folder are NOT deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | Yes | The folder ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that tables are not deleted, which is a non-obvious behavior. However, it omits details like required permissions, reversibility, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description is fairly complete. It explains the behavior regarding tables inside. Could mention if folder must be non-empty or what happens to the tables, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and folder_id is described. The description adds no additional parameter details beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (folder), and distinguishes itself by noting that tables inside the folder are not deleted, which contrasts with potential misunderstandings.
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 explicit guidance on when to use this tool versus siblings like delete_table or delete_rows. However, it implicitly clarifies a key behavioral difference (tables inside not deleted), offering some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific rows from a table by their row IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| row_ids | Yes | Array of row IDs to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose side effects, permanence, error handling for missing IDs, or authorization needs. For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, directly communicates the essential function. Concisely 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?
Adequate for a simple tool with two parameters and no output schema, but lacks behavioral context that would help an agent understand implications of deletion.
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 the description adds little beyond the schema. The schema already explains the parameters; the description only echoes the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (specific rows), and the method (by their row IDs). It distinguishes from sibling tools like delete_table and delete_column.
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 patch_rows or upsert_rows. No prerequisites or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a table and all its data.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'permanently delete', indicating irreversibility, which is important. However, no annotations exist, and the description fails to mention potential side effects like cascading deletions or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (6 words) and front-loaded with the action. While efficient, it could be slightly more verbose to include usage context without losing brevity.
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 delete operation with one parameter, the description is minimally adequate. However, given no output schema and no annotations, it lacks details about recovery, permissions, or related data impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and a single parameter, the description adds the 'permanently' qualifier beyond the schema. The schema already clearly describes the parameter's purpose.
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 deletes a table permanently, which is a specific action on a specific resource. It distinguishes from sibling tools like 'delete_column' and 'delete_rows' by explicitly mentioning 'table'.
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 deleting rows or moving a table to a folder. The description does not specify context or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific enrichment, including all required and optional parameters, response fields, pricing, and data source. Use this before running an enrichment to understand what parameters are needed.
| Name | Required | Description | Default |
|---|---|---|---|
| enrichment_id | Yes | The ID of the enrichment to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states that the tool returns required/optional parameters, response fields, pricing, and data source. This gives a good picture of the output content. It does not mention that it is read-only, but that is implied by 'get' and the description of returning information.
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 consists of two concise sentences. The first sentence states what the tool does and what it returns. The second sentence gives a clear usage scenario. No extraneous 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 tool has only one parameter and no output schema, the description is fairly complete. It explains what the tool returns (parameters, response fields, pricing, data source). It could mention that the enrichment_id must exist or that the tool is read-only, but these are minor 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?
There is only one parameter, and the schema already provides a clear description: 'The ID of the enrichment to get details for'. The tool description does not add any additional meaning beyond what the schema already provides. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a specific enrichment, listing included content (parameters, response fields, pricing, data source). It provides a usage hint ('Use this before running an enrichment') that distinguishes it from sibling tools like run_enrichment, which actually execute enrichments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before running an enrichment to understand what parameters are needed.' This is strong positive guidance on when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific exporter, including its required parameters and output fields. Use this to understand what parameters are needed before adding the exporter to a table.
| Name | Required | Description | Default |
|---|---|---|---|
| exporter_id | Yes | The exporter ID (from search_exporters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions what the tool returns (parameters and output fields) but does not disclose any behavioral aspects like authentication, rate limits, or side effects. As a read operation, this is acceptable but lacking.
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 efficiently convey purpose and usage. No redundant words; front-loaded with the main action and scope.
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 adequately explains what it returns and why to use it. It could be more complete by specifying the format of the returned details, but it is sufficient for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'exporter_id' has a clear description in the schema ('The exporter ID (from search_exporters)'). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('get detailed information') and resource ('specific exporter'), including contents ('required parameters and output fields'). It is distinct from sibling tools like 'get_table_exporters' and 'search_exporters' by focusing on a single exporter by ID, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case ('before adding the exporter to a table'), implying when to use it. However, it offers no guidance on when not to use it or alternatives, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available choices for a select/mselect enrichment parameter. Supports search and pagination. Use this when get_enrichment_details shows a parameter with choices.mode = "remote". For inline choices, the values are already included in get_enrichment_details.
| Name | Required | Description | Default |
|---|---|---|---|
| enrichment_id | Yes | The enrichment ID | |
| param_name | Yes | The parameter name (slug) | |
| q | No | Optional search query to filter choices by id or name | |
| page | No | Page number (default: 1) | |
| limit | No | Items per page (default: 100, max: 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It mentions search and pagination but does not state that the operation is read-only, safe, or any potential side effects. More context (e.g., no modifications, dependencies) 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 concise sentences that front-load the purpose and usage. No redundant or unnecessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description covers the key context (remote vs inline, search, pagination). It could be more complete by briefly describing the return format (e.g., list of choices with id and name), but it is sufficiently informative 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?
Schema coverage is 100%, so the schema already explains each parameter. The description adds 'supports search and pagination' which hints at q, page, limit, but this is not new meaning beyond the schema 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 clearly states the tool's purpose: 'Get available choices for a select/mselect enrichment parameter.' It also mentions support for search and pagination, which distinguishes it from related tools like get_enrichment_details.
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?
Explicitly states when to use this tool: 'Use this when get_enrichment_details shows a parameter with choices.mode = "remote".' It also tells when not to use it: 'For inline choices, the values are already included in get_enrichment_details.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all columns defined on a table. Returns column names, types, and identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the basic behavior (returns column info) but does not disclose potential errors, authorization needs, or whether it includes hidden columns. 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 a single sentence with no extraneous information. It is front-loaded 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?
Given the tool's simplicity (1 param, no output schema), the description is reasonably complete. It specifies what the tool returns. It could mention that the table must exist or error handling, but overall it suffices.
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 a single parameter well-described as 'The UUID of the table'. The description adds no extra information beyond the schema, so baseline score 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 explicitly states 'Get all columns defined on a table' and specifies the return value ('column names, types, and identifiers'). It clearly distinguishes from sibling tools that create, delete, or rename columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading table schema but does not explicitly state when to use it over alternatives, nor does it mention prerequisites like table existence 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.
List all enrichments configured on a table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether results are paginated, the ordering of results, or any permission requirements. This leaves the agent with insufficient information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and to the point. However, it lacks structure such as separating key points or front-loading critical 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?
With no output schema, the description does not explain what the returned list contains (e.g., IDs, objects, metadata). For a list operation, more detail is needed to understand the output 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?
The input schema covers 100% of the single parameter with a clear description. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'all enrichments configured on a table'. It is distinct from sibling tools like get_enrichment_details (for a single enrichment) and run_table_enrichment (for execution).
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 get_enrichment_details or search_enrichments. The description is purely functional and lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all exporters configured on a table. Returns exporter IDs that can be used with run_table_exporter.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists exporters and returns IDs, which is straightforward, but it does not explicitly declare it as a read-only operation or mention permissions or side effects. The name 'get' implies read-only, but explicit disclosure 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 short sentences that front-load the action and purpose. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description adequately covers its purpose and return value usage. It could mention the return format explicitly, but the lack of output schema reduces the need. Overall, complete enough for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter with a description ('The UUID of the table'). The description does not add any further meaning beyond what the schema already provides. With 100% 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?
Description clearly states the tool lists all exporters on a specific table and returns exporter IDs. The verb 'list' and resource 'exporters configured on a table' are specific, distinguishing it from sibling tools like 'add_table_exporter' or 'run_table_exporter'.
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 a usage scenario by mentioning that returned IDs can be used with 'run_table_exporter', but it does not explicitly state when to use this tool vs alternatives like 'search_exporters'. No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get rows from a table with pagination and optional filtering. Returns up to 100 rows per page by default (max 500). Supports Airtable-style structured filters with 5 operators: equals, contains, not_equals, is_empty, is_not_empty. Multiple filters use AND logic.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| page | No | Page number (default: 1) | |
| per_page | No | Rows per page (default: 100, max: 500) | |
| filter | No | Filter rows by column values (AND logic). Keys are column names, values are objects with one operator. Operators: equals, contains (case-insensitive), not_equals, is_empty (true), is_not_empty (true). Examples: {"company":{"contains":"tech"}}, {"status":{"equals":"active"}}, {"email":{"is_not_empty":true}}, {"name":{"contains":"a"},"revenue":{"equals":"5000"}} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains pagination limits and filtering behavior (AND logic, case-insensitive contains), but does not disclose response format, error handling, or potential side effects, though the read-only nature is implied.
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, uses front-loaded sentences to convey core purpose, and every sentence adds unique information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested filter object, no output schema), the description effectively covers pagination limits, operator details, and logical combination, leaving only response structure undocumented, which is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already details all parameters. The description adds value by explaining filter operators, case-insensitivity, and AND logic, and provides examples, which goes beyond the basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves rows from a table with pagination and filtering, which distinguishes it from sibling tools like create_rows, delete_rows, or patch_rows which modify data.
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 specifies when to use the tool (to read rows with pagination/filtering) and provides concrete limits (100 default, 500 max) and filtering operators, but does not explicitly mention when not to use it or suggest alternatives to siblings like get_table_columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all waterfalls installed on a table. Returns waterfall IDs that can be used with run_table_enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states it 'lists all waterfalls' and returns IDs, but omits details like error handling, permissions, or whether the list is paginated. This is minimal disclosure.
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 two sentences. It is front-loaded with the key action and adds a practical note about output usage. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description covers what the tool does and what it returns. It lacks details on edge cases or output format, but these are minor omissions for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already describes the parameter. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.
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 waterfalls on a table, with a specific verb and resource. It distinguishes from sibling tools like 'add_table_waterfall' and 'run_table_enrichment' by indicating the output can be used with the latter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the output is for use with 'run_table_enrichment', but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current user's credit balance and account information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as authentication requirements, read-only nature, rate limits, or what 'account information' includes beyond balance.
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 unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details about the return value (e.g., format of balance, additional account info). Given no output schema and no annotations, it is minimally complete but could be enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the description adds no parameter-specific information, which is acceptable. Baseline is 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current user's credit balance and account information'), which is specific and distinct from sibling tools that focus on tables, columns, folders, 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, no exclusions, and no context about prerequisites or typical use cases. The tool is simple, but zero guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all folders in your workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'List all folders' but does not disclose whether it includes subfolders, pagination, or read-only nature (implied). The behavior is straightforward but lacks detail on what 'all' encompasses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, efficient and front-loaded. It wastes no words but could be slightly more informative (e.g., mention output format) without losing 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 and no output schema, the description is mostly complete. However, it does not describe the return format (e.g., folder names, IDs) or scope (top-level only), which would help the agent understand what to expect.
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 zero parameters, so the input schema fully covers it (100% coverage). The description adds no further parameter information, which is appropriate. No additional semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all folders in your workspace' clearly indicates the tool lists folders (specific resource) and implies a read operation. It distinguishes from sibling tools like 'create_folder' and 'delete_folder' by focusing on listing, but lacks detail on scope (e.g., recursive or top-level only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly specify when to use this tool versus alternatives like 'list_tables' or 'create_folder'. Usage is implied: use when you need to see available folders. No exclusions or context about prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in your Databar workspace. Returns table UUIDs, names, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states what is returned but omits key details like whether the operation is read-only, any rate limits, or pagination behavior. The description is truthful but incomplete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences (10 words), with no unnecessary information. It directly states the action and output, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is complete. It explains the action and return values sufficiently. No additional context is needed for an agent to use 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?
The tool has 0 parameters, so the schema covers everything. The description adds value by explaining the output fields (UUIDs, names, timestamps) beyond the empty schema. This earns the baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all tables in your Databar workspace.' It specifies the return fields (UUIDs, names, timestamps), which distinguishes it from sibling tools like create_table or delete_table that perform different actions.
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 does not provide explicit guidance on when to use this tool versus alternatives. For a simple listing tool, the usage may be obvious, but no when-not or exclusion criteria are mentioned, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a table into a folder, or remove it from its current folder by passing folder_id as null.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table to move | |
| folder_id | No | Target folder ID, or null to remove from folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses mutation and null behavior but omits side effects, permission requirements, or error conditions. This is minimal 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?
Single sentence that is front-loaded and concise. Every word adds meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple operation with two params and no output schema. Could mention return value or error cases, but current level is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying the null behavior for folder_id, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a table into a folder, and explains the null behavior for removal. This is a specific verb+resource action that distinguishes it from folder creation or deletion siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like create_folder or list_folders. The description 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.
Update specific fields on existing rows by row ID (max 100 per request).
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| rows | Yes | Array of patch operations (max 100) | |
| overwrite | No | Overwrite non-empty cells (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry behavioral disclosure. It reveals the max 100 request limit, but does not mention the effect of the overwrite parameter (default true), idempotency, auth needs, return behavior, or partial failure handling. More detail would be beneficial.
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 that is front-loaded with purpose and includes a critical constraint. However, it could be more structured or broken into bullet points for clarity, but it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not hint at return values, error handling, or partial success behavior. For a tool that modifies data, this lacks completeness. The constraint on max rows is good, but more context on outcomes is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only the 'max 100 per request' constraint, which is already implied by maxItems in the schema. No additional semantic guidance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (existing rows), and the method (by row ID). It also includes a key constraint (max 100 per request), which distinguishes it from sibling tools like upsert_rows or create_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for updating existing rows, but does not explicitly state when to use this tool versus alternatives like upsert_rows (which handles insert-or-update) or create_rows (new rows). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing column on a table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| column_id | Yes | The UUID of the column to rename | |
| name | Yes | The new column name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without any behavioral details. It does not disclose whether the rename is reversible, what happens to dependencies, or any required permissions. 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, concise sentence that contains no fluff. It is appropriately sized for a simple rename operation and does not waste 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?
Given the tool has three required parameters, no output schema, and no annotations, the description is very minimal. It does not explain the return value, error conditions, or behavior upon success. This leaves the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with each parameter having a clear description (e.g., 'The UUID of the table'). The tool description does not add any additional meaning beyond what the schema already provides, receiving a 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 clearly states 'Rename an existing column on a table.' This is a specific verb+resource combination, and it distinguishes the tool from sibling tools like rename_table, create_column, and delete_column, which operate on different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., column must exist, permissions), and no when-not-to-use hints. The context is clear but lacks explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing folder.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | Yes | The folder ID | |
| name | Yes | The new folder name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like idempotency, permissions, or effects on contents; only states 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, effectively front-loading the purpose.
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 rename tool, the description is adequate but lacks details on return values or side effects; with no output schema, some behavioral context would improve 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?
Schema description coverage is 100% and the description adds no extra meaning beyond the schema's parameter descriptions, achieving 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 clearly states the verb 'rename' and resource 'folder', distinguishing it from sibling tools like create_folder, delete_folder, and rename_column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to rename a folder versus moving a table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| name | Yes | The new name for the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose any behavioral traits (side effects, permissions, immediate effect), leaving agent uninformed.
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 wasted words; appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple operation, description omits return value, confirmation, or side effects. Given no output schema, more detail is needed 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?
Schema description coverage is 100%, so baseline is 3. Description adds no extra parameter meaning beyond schema fields.
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 'Rename an existing table' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_table or delete_table.
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., move_table_to_folder for moving, not renaming; or rename_column for columns). Missing 'when not to use' cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an enrichment on multiple inputs at once. Provide an array of parameter objects. Subject to spending limits. For paginated enrichments, use the pages parameter to fetch multiple pages per record (each page per record is billed separately).
| Name | Required | Description | Default |
|---|---|---|---|
| enrichment_id | Yes | The ID of the enrichment to run | |
| params_list | Yes | Array of parameter objects, one per record | |
| pages | No | Number of pages to fetch per record for paginated enrichments (default: 1, max: 100). Each page per record is billed separately. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses spending limits and billing for pages, but does not specify whether the operation is atomic, if errors are per-record, or if it's read/write. Adequate but not rich.
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?
Three sentences, no filler, front-loaded with purpose. Every sentence adds information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases and billing, but lacks return value description (no output schema) and error handling for bulk operations. Acceptable for a simple tool, but could be more 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%, baseline 3. Description adds value by explaining that params_list is an array of parameter objects and that pages parameter is for paginated enrichments with billing context. Adds beyond 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?
Clearly states 'Execute an enrichment on multiple inputs at once', specifying the verb (execute), resource (enrichment), and scope (multiple inputs). This distinguishes it from siblings like run_enrichment (likely single input) and run_bulk_waterfall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on how to use: 'Provide an array of parameter objects' and for paginated enrichments use the pages parameter. Mentions spending limits. Does not explicitly contrast with alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a waterfall enrichment on multiple inputs at once. Subject to spending limits.
| Name | Required | Description | Default |
|---|---|---|---|
| waterfall_identifier | Yes | The identifier of the waterfall to run | |
| params_list | Yes | Array of parameter objects, one per record | |
| provider_ids | No | Optional: Specific provider IDs to use | |
| email_verifier | No | Optional: Email verifier enrichment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It only mentions spending limits, but does not state side effects (e.g., mutating data, costs, idempotency). Lacks clarity on boundaries or required permissions.
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 with no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too minimal. It lacks explanation of return values, error handling, or how spending limits affect execution.
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 the schema already documents parameters. The description adds no extra meaning for any parameter, making it baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a waterfall enrichment on multiple inputs at once. It distinguishes from run_waterfall (single input) but not clearly from run_bulk_enrichment or other bulk tools.
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?
Only mentions spending limits as a constraint. No guidance on when to use this tool versus alternatives like run_bulk_enrichment or run_waterfall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a data enrichment with the provided parameters. Automatically handles async execution and polling, returning final results. Results are cached for 24 hours to reduce costs. Subject to spending limits (DATABAR_MAX_COST_PER_REQUEST, DATABAR_MIN_BALANCE). For paginated enrichments, use the pages parameter to fetch multiple pages (each page is billed separately).
| Name | Required | Description | Default |
|---|---|---|---|
| enrichment_id | Yes | The ID of the enrichment to run | |
| params | Yes | Parameters required by the enrichment (e.g., {"email": "test@example.com"}) | |
| skip_cache | No | Skip cache and fetch fresh data (default: false) | |
| pages | No | Number of pages to fetch for paginated enrichments (default: 1, max: 100). Each page is billed separately. Use get_enrichment_details to check if pagination is supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers async execution, polling, caching (24 hours), spending limits, and per-page billing. Missing details on error handling or partial results, but major behaviors are disclosed.
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?
Four concise sentences, each adding necessary information. No fluff, well-structured with key points front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, it covers usage, caching, limits, and pagination. Could mention return format, but overall complete enough for agent to use 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 coverage is 100%, baseline 3. Description adds value by explaining pages billing, caching skip behavior, and hinting at enrichment_details for pagination support. Enhances understanding 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?
The description clearly states the tool executes a data enrichment, handles async execution and polling, and returns final results. It distinguishes from siblings by focusing on a specific enrichment ID rather than table-level enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides actionable guidance: mentions caching (reduces costs), spending limits, and pagination usage with reference to get_enrichment_details for checking pagination. Lacks explicit comparison to run_table_enrichment but still offers good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an enrichment or waterfall to run on a table. By default runs on all rows. Optionally specify row_ids to run on specific rows, and run_strategy to control row selection. Works for both enrichments (from add_table_enrichment) and waterfalls (from add_table_waterfall). Subject to spending limits.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| enrichment_id | Yes | The table enrichment/waterfall ID to run (returned by add_table_enrichment or add_table_waterfall) | |
| row_ids | No | Optional: specific row IDs to process. When omitted, processes all rows. | |
| run_strategy | No | Which rows to process: 'run_all' (default) runs every row, 'run_empty' skips rows that already have a result, 'run_errors' reruns only rows that ended with an error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions triggering runs and spending limits but lacks details on asynchronicity, return value, or handling of concurrent runs. Moderate 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 concise sentences: first states core action, second elaborates on options and constraints. No filler, front-loaded, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter set and lack of output schema, the description adequately explains purpose and optional parameters. It references spending limits, which is a key constraint. Missing details on execution behavior are minor given the tool's simplicity.
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 context by explaining default behavior for row_ids and run_strategy, and clarifying that the tool works for both enrichments and waterfalls, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers an enrichment or waterfall to run on a table, specifying the action and resource. It distinguishes from siblings that run on specific enrichments/waterfalls (like run_enrichment, run_waterfall) by emphasizing it operates on a table.
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 explains default behavior (runs all rows), optional parameters (row_ids, run_strategy), and applicable types (enrichments and waterfalls). It also mentions spending limits, guiding appropriate use. However, it could explicitly contrast with bulk-run siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an exporter to run on a table. By default runs on all rows. Use run_strategy to control row selection. Subject to spending limits.
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| exporter_id | Yes | The table exporter ID to run (returned by add_table_exporter) | |
| run_strategy | No | Which rows to process: 'run_all' (default) runs every row, 'run_empty' skips rows that already have a result, 'run_errors' reruns only rows that ended with an error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions spending limits, but fails to disclose sync/async nature, return value, error handling, or authorization requirements. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. No unnecessary words 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?
No output schema. Missing critical details: return format, asynchronous behavior, error scenarios, rate limits. For a trigger tool with no annotations, this is insufficient.
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% coverage, so baseline is 3. Description adds minor value for run_strategy but no additional context for table_uuid or exporter_id. Marginal improvement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger an exporter to run on a table'), with a specific verb and resource. It distinctly separates from sibling tools like add_table_exporter (add vs run).
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?
Mentions default behavior and run_strategy options, but lacks explicit guidance on when not to use this tool or how it differs from run_enrichment/run_waterfall. Adequate but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a waterfall enrichment that tries multiple providers until one succeeds. Subject to spending limits.
| Name | Required | Description | Default |
|---|---|---|---|
| waterfall_identifier | Yes | The identifier of the waterfall to run (e.g., "email_getter") | |
| params | Yes | Parameters required by the waterfall | |
| provider_ids | No | Optional: Specific provider IDs to use (default: uses all in cost-optimized order) | |
| email_verifier | No | Optional: Email verifier enrichment ID to verify results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that it tries multiple providers until one succeeds and is subject to spending limits, which provides some behavioral context. However, with no annotations, it lacks details on side effects, error handling, or whether it modifies 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?
Two sentences, no unnecessary words. The first sentence captures the core purpose. Slightly more structured could improve readability, but it's concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple providers, spending limits, nested params), the description is too brief. It doesn't explain return values, error scenarios, or how spending limits are enforced, leaving 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?
Input schema has 100% description coverage, so parameters are already documented. The description adds no extra meaning beyond what the schema provides, meeting 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?
Description clearly states it executes a waterfall enrichment that tries multiple providers until success. The verb 'execute' and resource 'waterfall enrichment' are specific. However, it does not differentiate from sibling tools like run_bulk_waterfall or run_enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It mentions spending limits but does not specify prerequisites or scenarios for choosing this over other enrichment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and discover available data enrichments. Use this to find the right enrichment for a specific task (e.g., "linkedin profile", "email finder", "company data"). Returns a list of matching enrichments with their IDs, descriptions, required parameters, and pricing. Results are sorted by recommendation rank (best options first). BYOK providers that the user has not connected are automatically excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find enrichments (e.g., "linkedin", "email verification", "company data", "job postings", "tech stack") | |
| category | No | Optional: Filter by category name (e.g., "Company Data", "Contact Finding", "Hiring Signals", "Tech Stack", "SEO", "Reviews") | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses that BYOK providers not connected are excluded and results are sorted by recommendation rank. This adds important behavioral context without contradicting any structured 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?
Two sentences, front-loaded with purpose, each sentence adds distinct value. No redundant or missing information. Achieves optimal 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?
For a search tool with no output schema, the description adequately covers what the tool does, its inputs, and what it returns (IDs, descriptions, required parameters, pricing). No gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description provides examples for query ('linkedin', 'email verification'), explains category as optional with examples, and mentions limit default. This adds value 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 clearly states it searches and discovers available data enrichments, with concrete examples ('linkedin profile', 'email finder'). It distinguishes itself from siblings like get_enrichment_details and run_enrichment by focusing on discovery.
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?
It explicitly says to use this to find the right enrichment for a specific task. While it doesn't list when not to use alternatives, the context of siblings like search_exporters and run_enrichment provides clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and discover available data exporters (CRM/destination integrations). Use this to find the right exporter for pushing data to external services (e.g., "Google Sheets", "HubSpot", "Salesforce"). Returns a list of matching exporters with their IDs and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find exporters (e.g., "google sheets", "hubspot", "salesforce", "crm") | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses that it returns 'a list of matching exporters with their IDs and descriptions'. Does not mention any destructive side effects; it is a read-only search. Could be improved by noting search behavior (e.g., case sensitivity, matching fields) but adequate.
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, no redundancy. First sentence states purpose, second provides usage context and return info. Front-loaded with key action and resource.
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 output schema, description compensates by stating return content. Parameters are well-documented with examples. Sufficient for an agent to understand and 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 coverage is 100% (both parameters have descriptions). The description adds value by including example queries (e.g., 'google sheets', 'hubspot') and specifying the default limit. Also states the return format (list with IDs and descriptions), which is not in 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?
Description clearly states 'search and discover available data exporters (CRM/destination integrations)' with specific examples like 'Google Sheets', 'HubSpot', 'Salesforce'. Differentiates from siblings like 'search_enrichments' and 'search_waterfalls' by focusing on exporters for pushing data to external services.
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?
Explicitly says 'Use this to find the right exporter for pushing data to external services' and provides example queries. Does not explicitly state when not to use or mention alternatives, but context implies use for discovery rather than detail retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available waterfall enrichments. Waterfalls try multiple data providers in sequence until one succeeds, maximizing data retrieval success rate.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., "email finder", "phone lookup") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains that waterfalls try multiple providers sequentially, but with no annotations, lacks details on side effects, auth requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with key information front-loaded; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool with one parameter; could be more specific about the format or structure of results, but sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter description is already clear; description adds no extra meaning for the query parameter beyond contextual understanding of waterfalls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches for waterfall enrichments and explains the waterfall concept, distinguishing it from sibling tools like search_enrichments and run_waterfall.
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?
Purpose is clear but no explicit guidance on when to use this tool versus alternatives 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.
Insert or update rows by matching key (max 100 per request).
| Name | Required | Description | Default |
|---|---|---|---|
| table_uuid | Yes | The UUID of the table | |
| rows | Yes | Array of upsert operations (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (upsert by key) and a constraint (max 100). However, as no annotations are provided, it omits details like whether updates are partial or full, what happens on duplicate keys, or required permissions. It covers basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the operation, mechanism, and constraint. Every word is meaningful and well-placed, with no redundancy or unnecessary detail.
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 and the absence of an output schema, the description covers the essentials. However, it lacks details on response format, error behavior, and how it compares to sibling tools, which would make it more complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters, but the description adds critical context: 'by matching key' clarifies that the 'key' property in the rows array is used for matching existing rows. This goes beyond the schema's property descriptions, which are minimal.
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 operation: 'Insert or update rows by matching key'. It specifies the resource (rows) and the action (upsert), distinguishing it from siblings like 'create_rows' (insert only) and 'patch_rows' (update only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives such as 'create_rows' or 'patch_rows'. It does not mention prerequisites, edge cases, or scenarios where this tool is preferred, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.4.0add_table_enrichmentadd_table_exporteradd_table_waterfallcreate_columncreate_foldercreate_rowscreate_tabledelete_columndelete_folderdelete_rowsdelete_tableget_enrichment_detailsget_exporter_detailsget_param_choicesget_table_columnsget_table_enrichmentsget_table_exportersget_table_rowsget_table_waterfallsget_user_balancelist_folderslist_tablesmove_table_to_folderpatch_rowsrename_columnrename_folderrename_tablerun_bulk_enrichmentrun_bulk_waterfallrun_enrichmentrun_table_enrichmentrun_table_exporterrun_waterfallsearch_enrichmentssearch_exporterssearch_waterfallsupsert_rowsEach tool has a clearly distinct purpose, covering separate operations like CRUD for tables/columns/rows, discovery and execution of enrichments/exporters/waterfalls, and configuration management. Overlaps like run_enrichment vs run_bulk_enrichment are well-differentiated by scope.
Tool names follow a consistent verb_noun pattern (e.g., create_table, search_enrichments, run_waterfall). Even less common names like patch_rows and upsert_rows fit the pattern. No mixing of conventions or vague verbs.
With 37 tools, the server covers a broad domain (table management, enrichment workflows, export, waterfalls). While slightly above the typical well-scoped range, each tool addresses a specific need and the count is justified by the feature set.
Core CRUD for tables, columns, rows, folders is present, and enrichment/export/waterfall workflow is covered. However, missing removal operations for table-level configurations (no delete_table_enrichment or remove_table_exporter) leave a notable gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search companies, enrich contacts, and reveal emails and phones from your AI agent.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/databar-ai/databar-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
