B2B data enrichment tools for any MCP-compatible AI client — find emails, enrich LinkedIn profiles, search companies, and more.
Tools are dynamically loaded from the Derrick API at startup, so new actions are available automatically.
A Derrick account with the Standard plan ($20/mo) or above
An API key (get it from: Google Sheets > Derrick menu > burger icon > API)
Node.js 22+
Related MCP server: GOD MODE INTEL MCP Server
Edit your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"derrick": {
"command": "npx",
"args": ["derrick-mcp"]
}
}
}Add to .mcp.json at your project root (or ~/.claude/settings.json for global):
{
"mcpServers": {
"derrick": {
"command": "npx",
"args": ["derrick-mcp"]
}
}
}Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"derrick": {
"command": "npx",
"args": ["derrick-mcp"]
}
}
}Any client that supports the MCP protocol over stdio can use this server.
The command is npx derrick-mcp.
Once connected, tell the AI:
"Configure Derrick with my API key: YOUR_KEY"
The key is saved to ~/.derrick-mcp/.env and persists across sessions.
Two built-in tools are always available:
Tool | Description |
| Save your API key |
| Check your credits and account info |
All other tools (find email, enrich profile, search company, etc.) are loaded dynamically from the API. Ask the AI "What can Derrick do?" to see the full list.
Instead of using derrick_configure, you can set the API key as an environment variable:
{
"mcpServers": {
"derrick": {
"command": "npx",
"args": ["derrick-mcp"],
"env": {
"DERRICK_API_KEY": "your-key-here"
}
}
}
}cd MCP
npm install
npm run build # compile TypeScript
npm run dev # run with tsx (hot reload)
npm start # run compiled versionProduct site: https://derrick-app.com
Email: contact@derrick-app.com
Privacy policy: https://derrick-app.com/privacy
Terms of service: https://derrick-app.com/terms
MIT — see LICENSE.
Check your Derrick account info and remaining credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description adds minimal value beyond stating the tool checks account info and credits. It does not describe the return format, specific fields, or any side effects, which would be helpful since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action ('Check your Derrick account info and remaining credits'). Every word serves a purpose with no redundancy or fluff.
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, parameterless tool with annotations, the description is minimally adequate but lacks detail about what 'account info' includes (e.g., email, name, credits). Without an output schema, more specificity would help the agent understand the return value. It is complete enough for basic use but leaves room for improvement.
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 are zero parameters and schema description coverage is 100%, so the description does not need to elaborate on parameters. The mention of 'account info and remaining credits' gives a hint about the output but is not required for parameter semantics. Baseline of 4 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 checks Derrick account info and remaining credits, using a specific verb ('Check') and resource. This distinguishes it from sibling tools like derrick_credits (which likely focuses only on credits) and derrick_configure (for settings), leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as derrick_credits for checking only credits. The agent must infer usage context from the name and description, which is insufficient for optimal tool selection among 21 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save your Derrick API key locally. To get your key: install the Derrick Google Sheets extension (https://derrick-app.com), open a sheet > Derrick menu > burger icon > API. Requires Standard plan (€20/mo) or above.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your Derrick API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description 'Save ... locally' is consistent with idempotentHint=true. Adds plan requirement but does not elaborate on side effects or beyond 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?
Three sentences, front-loaded with main action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration tool with one parameter and annotations, the description covers purpose, obtaining key, and prerequisite adequately.
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 covers 100% with basic description. Description adds value by specifying where to obtain the key and the required plan.
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 verb 'save' and resource 'Derrick API key locally'. Distinguished from siblings as the only configuration tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides instructions on obtaining the key and prerequisite plan. Implicitly indicates this must be used before other Derrick tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the last known Derrick credits balance. Reads from an in-memory cache updated after every API call — no network round-trip. Call this when the user asks how many credits they have left. Always reply in the user's language.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by revealing it reads from an in-memory cache (no network round-trip) and returns the last known balance, potentially stale. No contradictions with 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?
Three sentences, each earning its place: purpose, behavioral detail, usage context, and a language instruction. No redundancy and front-loaded efficiently.
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 parameterless tool with no output schema, the description is largely complete. It explains caching and language handling, though it could optionally specify the return format (e.g., a number). Still, it provides sufficient contextual guidance.
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 are no parameters, so the description cannot add parameter meaning. With 100% schema coverage and zero params, a baseline of 4 is appropriate as the description covers the tool's input needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows 'the last known Derrick credits balance', using a specific verb and resource. It distinguishes itself from sibling tools like derrick_account, which would cover broader account info.
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 'Call this when the user asks how many credits they have left', providing clear context for use. It does not mention when not to use it or alternatives, but the guidance is sufficient for the tool's simple purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich Company with SIRET & SIREN Enrichit une entreprise française via SIRET/SIREN avec identité, activité, dirigeants et données légales. Cost: 1 credit(s) per call. Category: enrich::company
FRENCH COMPANIES ONLY. Do NOT call this for non-French companies. Accepts SIRET (14 digits) or SIREN (9 digits). Returns 30+ legal fields: name, address, NAF code, revenue, net result, directors, etc.
Args: siret: SIRET (14 chiffres) OU SIREN (9 chiffres)
| Name | Required | Description | Default |
|---|---|---|---|
| siret | Yes | SIRET (14 chiffres) OU SIREN (9 chiffres) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds cost, category, and field count (30+ fields), providing useful context beyond annotations. No contradiction.
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?
Front-loaded with title and key purpose. Includes useful but slightly redundant info (args section repeats schema). Could be more concise by merging the parameter explanation.
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 adequately explains return fields (30+ legal fields) and includes cost and category. Sufficient for a simple single-parameter 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?
Input schema has 100% coverage for the single parameter 'siret', which is described. Description adds the French-only restriction and clarifies that it accepts both SIRET and SIREN, adding marginal value 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?
Description clearly states the tool enriches French companies using SIRET/SIREN, with specific verb and resource. Differentiates from siblings like derrick_enrich_companies and derrick_enrich_profile by specifying the French-only, government data source.
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 'FRENCH COMPANIES ONLY' and specifies input format (14-digit SIRET or 9-digit SIREN). However, no explicit alternatives for non-French companies are given, though the sibling list implies other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich Company with LinkedIn Data Enrich companies with +15 attributes from a LinkedIn company URL Cost: 1 credit(s) per call. Category: enrich::linkedin::company
Adds +15 LinkedIn attributes (name, description, industry, size, location, website, followers, specialties, etc.). Requires a full LinkedIn URL — if you only have the name, use search_companies first (+1 credit). Requires the Derrick Chrome extension.
Args: queryValue: LinkedIn company URL column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | LinkedIn company URL column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost, extension requirement, and enrichment behavior. Consistent with readOnlyHint and openWorldHint annotations, adding useful context beyond 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?
Concise, front-loaded with title and summary, followed by requirements and args. 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?
Covers purpose, prerequisites, alternatives, cost, and category. Complete for a single-parameter enrichment tool with 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% for the single parameter, and the description repeats the schema description without adding further meaning. 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 enriches companies with +15 LinkedIn attributes using a LinkedIn URL. It distinguishes itself from sibling tools like derrick_enrich_profile and derrick_search_companies.
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 guides when to use: requires full LinkedIn URL; if only name, use search_companies first. Also notes the Derrick Chrome extension requirement and credit cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich LinkedIn Profile with Data Enrich profiles with +15 attributes from a LinkedIn profile URL Cost: 1 credit(s) per call. Category: enrich::linkedin::lead::essential
Adds +15 attributes (name, headline, company, location, summary, education, etc.). Requires the Derrick Chrome extension installed and connected — empty responses usually mean the extension is not connected. If the user only has a name, suggest: search_linkedin_profile (1) + enrich_profile (1) = 2 credits total.
Args: queryValue: LinkedIn profiles URL column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | LinkedIn profiles URL column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds cost, category, attributes list, and extension dependency, but does not disclose failure modes or rate limits beyond empty responses.
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 mostly concise with a clear structure (bullet points), but the title and first sentence are redundant.
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?
Completeness is good given the single parameter and no output schema; lists attributes and extension requirement, but output format is not described.
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% (queryValue described as 'LinkedIn profiles URL column'), so the description repeats this without adding new semantic 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 enriches LinkedIn profiles with +15 attributes from a URL, distinguishing it from siblings like search_linkedin_profile (search) and enrich_companies (companies).
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 explicit guidance: requires Chrome extension, explains empty response meaning, and suggests an alternative workflow (search then enrich) if only a name is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Work Email Find professional email from Fullname, Company name & Linkedin Company URL. Cost: 5 credit(s) per call. Category: find::lead::essential
Charged ONLY on success (5 credits per email found). If the LinkedIn company URL is unknown, suggest chaining: search_companies (1 credit) + find_email (5 credits) = 6 credits total. Always announce the total before calling and wait for confirmation.
Args: fullName: Select fullName column: company: Select company column: linkedinCompanyURL (optional): Select linkedin company url column:
| Name | Required | Description | Default |
|---|---|---|---|
| fullName | Yes | Select fullName column: | |
| company | Yes | Select company column: | |
| linkedinCompanyURL | No | Select linkedin company url column: |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds important behavioral details: cost per call (5 credits), charged only on success, and chaining suggestion. No contradictions with annotations, and adds value beyond them.
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 well-structured with purpose first, then cost, chaining advice, and parameter list. It is not overly verbose, though the parameter list duplicates schema info. Every sentence adds value except perhaps minor 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?
Given the tool's simplicity and the presence of annotations and full schema coverage, the description is sufficiently complete. It covers purpose, cost, usage guidance, and parameter listing. It does not describe return values, but no output schema exists and the openWorldHint suggests a flexible response.
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's parameter list essentially restates the schema descriptions. It does not add new meaning or constraints beyond what the schema already provides, so 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 it finds professional email from Fullname, Company name, and LinkedIn Company URL. It is specific and matches the title, but does not explicitly distinguish from sibling tools like find_phone or find_gender, though the purpose is evident.
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 explicit guidance on when to use this tool, including chaining with search_companies if LinkedIn URL is unknown. Also instructs to announce total cost before calling and wait for confirmation, which is very helpful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Gender from Name Remove all special characters from a full name and find their firstname, lastname and gender. Cost: 1 credit(s) per call. Category: clean
Strips special characters from a full name and returns firstname, lastname, and gender.
Args: queryValue: Select fullname column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Select fullname column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by disclosing the cost (1 credit per call), the category (clean), and the preprocessing step (stripping special characters). This goes beyond the annotations and provides useful 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?
The description is front-loaded with the purpose but is somewhat repetitive: 'Find Gender from Name' appears twice, and the stripping of special characters is stated twice. It could be more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the processing, cost, and purpose. It lacks details on the output format or when to use it, but given low complexity, it is mostly 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?
The input schema fully describes the parameter (queryValue) with 'Select fullname column'. The description adds that the tool removes special characters from the full name, which enriches the parameter semantics by explaining how the input is processed.
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 finds gender from a name, and explains it extracts firstname, lastname, and gender after removing special characters. This directly conveys the purpose and differentiates it from sibling tools like derrick_find_email or derrick_enrich_profile.
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 guidelines on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or when not to use it. It only implies usage via the description of the input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Mobile Phone from LinkedIn Profile Find any phone from Linkedin Regular Profil Url. Cost: 150 credit(s) per call. Category: find::Lead::Essential
HIGH COST: 150 credits per phone found. Charged ONLY on success. ALWAYS announce the cost in bold before calling and wait for explicit confirmation. If the user only has a name, mention chaining: search_linkedin_profile (1) + find_phone (150) = 151 credits total.
Args: linkedinProfilUrl: Select LinkedinUrl :
| Name | Required | Description | Default |
|---|---|---|---|
| linkedinProfilUrl | Yes | Select LinkedinUrl : |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, which are consistent. The description adds behavioral details: high cost of 150 credits, success-based charging, and the need for confirmation. No contradictions with 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 structured with a title, cost notice, usage instructions, and args list. It is somewhat verbose with repetition of the title, but each section adds useful information. Could be more concise but still 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?
Given no output schema, the description does not explain the return value format, whether multiple phones can be found, or error handling. For a simple tool with one parameter, it covers usage well but lacks output semantics.
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 only restates the parameter name and purpose. No additional format, validation, or example beyond what the schema provides. Therefore, it meets the baseline but adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a mobile phone from a LinkedIn profile URL. The verb 'find' and resource 'mobile phone' are explicit, and it distinguishes itself from sibling tools like derrick_find_email or derrick_find_gender.
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 explicit instructions: announce cost in bold and wait for confirmation, explains chaining with search_linkedin_profile when only a name is given, and notes that the cost is charged only on success. This gives clear when-to-use and how-to-handle context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich Company with Website Technologies Get website technology (CMS, Framework, Analytics, CDN, Hosting, etc.) Cost: 2 credit(s) per call. Category: enrich::Company
Detects CMS, framework, analytics, CDN, hosting. Useful for qualifying prospects by stack. Charged 2 credits even if no tech is detected.
Args: website_url: Choose Website URL
| Name | Required | Description | Default |
|---|---|---|---|
| website_url | Yes | Choose Website URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses the cost (2 credits per call), the fact that credits are charged even if no tech is detected, and the categories of technologies detected. This adds valuable 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?
The description is concise (a few lines), front-loads the core purpose and detected technologies, and every sentence adds value (cost, category, usage hint, credit policy). No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description outlines the types of technologies detected, which implies the output structure. It also covers cost and credit implications. For a simple single-parameter tool, this is fairly complete, though explicit output format (e.g., list or JSON) is missing.
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 'website_url' has schema description 'Choose Website URL', which is identical in the tool description. No additional meaning or format guidance is provided. Since schema coverage is 100%, baseline is 3, and the description does not enhance parameter semantics.
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 tool's title 'Enrich Company with Website Technologies' and description explicitly state it detects CMS, framework, analytics, CDN, hosting on a website. This clearly identifies the purpose and distinguishes it from sibling enrichment tools like derrick_enrich_companies or derrick_find_email.
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 mentions it's 'useful for qualifying prospects by stack', providing context for use. However, it does not specify when to avoid using it or suggest alternative tools for similar tasks (e.g., derrick_search_companies for company data). Usage guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Name from Email Find firstname, lastname and domain from an email. Cost: 0 credit(s) per call. Category: clean
Extracts firstname, lastname, and domain from an email address. Useful for cleanup and parsing.
Args: queryValue: Select email column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Select email column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=true and openWorldHint=true, so the description does not need to restate those. The description adds value by disclosing the cost (0 credits) and category (clean), which are behavioral traits beyond the annotations. However, it does not mention error handling for invalid email formats or expected input constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains some redundancy (first sentence repeats the title). The inclusion of 'Cost: 0 credit(s) per call. Category: clean' adds context but could be placed elsewhere. The structure is adequate but not optimally 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?
There is no output schema, yet the description does not explain the return format (e.g., JSON object with keys firstname, lastname, domain). It mentions extracting these fields but lacks detail on the response structure. For a simple tool, this might suffice, but it is not fully 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% for the single parameter 'queryValue', with its description 'Select email column' matching the description's args line. The description adds no additional semantics beyond what the schema provides, such as expected format or examples. Baseline 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: extracting firstname, lastname, and domain from an email address. It uses specific verbs like 'find' and 'extract', and specifies the resource (email) and output fields. This distinguishes it from sibling tools like derrick_find_email or derrick_verify_email, which have different goals.
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 mentions 'useful for cleanup and parsing,' which gives a general context. However, it does not explicitly specify when to use this tool versus alternatives like derrick_enrich_profile or derrick_search_linkedin_profile. There is no guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ALWAYS call this tool when the user asks anything about Derrick itself: what it is, what it does, how it works, what features exist, how billing works, what plans exist, what errors mean, or how to scale up. Do NOT answer from memory — call this tool first.
Triggers (any language): "what is derrick", "what does it do", "how does it work", "my credits", "how many credits", "errors", "pricing", "plans", "at scale", "in bulk", "c'est quoi derrick", "ça fait quoi", "mes crédits", "les prix", "à grande échelle".
Always reply in the user's language and tone.
Args: topic (optional): "credits", "errors", "pricing", "scale", "features", or empty for the full overview.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | One of: credits, errors, pricing, scale, features. Empty for full overview. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds behavioral context: reply in user's language/tone, and describes parameter behavior. No contradictions, and it enriches beyond 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 well-structured with clear sections (usage, triggers, language note, args). It is fairly concise, though the trigger list could be slightly trimmed. Efficient for the content provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description is complete: covers purpose, when to call, parameter details, and response style. Missing output format is acceptable for a help 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?
Parameter schema covers 100% with description listing allowed values. The description adds the 'empty for full overview' guideline, but this is also implied by the schema. Baseline 3 is appropriate as the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides information about 'Derrick itself' (what it is, features, billing, etc.). It distinguishes from sibling tools which handle specific operations like searching or account management. Trigger phrases further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS call this tool when the user asks anything about Derrick itself' and 'Do NOT answer from memory — call this tool first.' It provides trigger phrases but does not explicitly list when not to use it or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich LinkedIn Profile with Followers & Connections Count Enrich profiles with follower & connections count Cost: 1 credit(s) per call. Category: enrich::linkedin::lead
Returns followers, connections count, and creator/verified status. Useful for qualifying influencers or checking notoriety. Requires the Derrick Chrome extension.
Args: queryValue: LinkedIn profiles URL column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | LinkedIn profiles URL column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses cost (1 credit per call), required software (Chrome extension), and specific return data (followers, connections, status). This adds 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?
The description is concise and well-structured, with a clear summary, bullet-like details, and cost. Some redundancy in repeating the title in the description is minor.
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 purpose, input, return values, prerequisites, and cost. It covers all necessary 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 description repeats the schema's parameter description verbatim without adding new semantic details. With 100% schema coverage, this 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 enriches LinkedIn profiles with followers and connections count, and explicitly lists return values. It distinguishes from siblings by focusing on a specific metric, but could more explicitly contrast with derrick_enrich_profile.
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 use cases (qualifying influencers, checking notoriety) and prerequisites (Chrome extension), but does not explicitly compare with alternative tools or state 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.
Push lead to La Growth Machine List LinkedIn employees of a company (name, role, location, profile URL). Cost: 1 credit(s) per call. Category: push::linkedin::lead::test
Args: audienceId: Lgm audience to use linkedinUrl: Lead LinkedIn profile URL firstname (optional): Firstname lastname (optional): Lastname gender (optional): Gender (man or woman) bio (optional): Bio companyName (optional): Company name companyUrl (optional): Company URL jobTitle (optional): Job title profilePicture (optional): Profile picture URL twitter (optional): Twitter handle or URL proEmail (optional): Professional email persoEmail (optional): Personal email industry (optional): Industry phone (optional): Phone number crm_id (optional): CRM ID location (optional): Location relationsCount (optional): Relations count leadId (optional): Lead ID customAttribute1 (optional): Custom Attribute 1 customAttribute2 (optional): Custom Attribute 2 customAttribute3 (optional): Custom Attribute 3 customAttribute4 (optional): Custom Attribute 4 customAttribute5 (optional): Custom Attribute 5 customAttribute6 (optional): Custom Attribute 6 customAttribute7 (optional): Custom Attribute 7 customAttribute8 (optional): Custom Attribute 8 customAttribute9 (optional): Custom Attribute 9 customAttribute10 (optional): Custom Attribute 10
| Name | Required | Description | Default |
|---|---|---|---|
| audienceId | Yes | Lgm audience to use | |
| linkedinUrl | Yes | Lead LinkedIn profile URL | |
| firstname | No | Firstname | |
| lastname | No | Lastname | |
| gender | No | Gender (man or woman) | |
| bio | No | Bio | |
| companyName | No | Company name | |
| companyUrl | No | Company URL | |
| jobTitle | No | Job title | |
| profilePicture | No | Profile picture URL | |
| No | Twitter handle or URL | ||
| proEmail | No | Professional email | |
| persoEmail | No | Personal email | |
| industry | No | Industry | |
| phone | No | Phone number | |
| crm_id | No | CRM ID | |
| location | No | Location | |
| relationsCount | No | Relations count | |
| leadId | No | Lead ID | |
| customAttribute1 | No | Custom Attribute 1 | |
| customAttribute2 | No | Custom Attribute 2 | |
| customAttribute3 | No | Custom Attribute 3 | |
| customAttribute4 | No | Custom Attribute 4 | |
| customAttribute5 | No | Custom Attribute 5 | |
| customAttribute6 | No | Custom Attribute 6 | |
| customAttribute7 | No | Custom Attribute 7 | |
| customAttribute8 | No | Custom Attribute 8 | |
| customAttribute9 | No | Custom Attribute 9 | |
| customAttribute10 | No | Custom Attribute 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint: true, but the tool name and description indicate a write operation ('push lead'). This is a direct contradiction. The description does not address the write nature, permissions, side effects, or any behavioral traits beyond cost, failing to compensate for the misleading annotation.
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 overly long with 29 parameter lines that simply duplicate the schema. The first line is misleading, and the structure is a flat list without grouping or prioritization. It is not concise and front-loads irrelevant info.
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 29 parameters, no output schema, and contradictory annotations, the description is incomplete. It omits what happens after pushing, error handling, data constraints, and integration details. The cost mention is useful but 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 coverage is 100%, so each parameter has a description in the schema. The description merely repeats those same descriptions without adding new meaning or clarifying relationships between parameters. The baseline of 3 is appropriate as no additional value is provided.
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 says 'Push lead to La Growth Machine' but then immediately includes an unrelated line about 'List LinkedIn employees of a company', causing confusion about the tool's actual purpose. The core action of pushing a lead is clear from the title, but the contradictory description undermines clarity.
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 sibling tools. The description only mentions cost per call but does not specify prerequisites, alternatives, or scenarios where this tool is preferred or should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Linkedin Company Profile from Name Search company Linkedin URL from company name Cost: 1 credit(s) per call. Category: find::linkedin::company::essential
ENTRY POINT for company workflows — use this BEFORE enrich_companies. Also produces the linkedinCompanyURL needed by find_email. The "confidence" field is hidden by the formatter — never ask for it. When chaining with enrich_companies, announce total (1 + 1 = 2 credits).
Args: queryValue: Company name column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Company name column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds credit cost, a warning about the hidden 'confidence' field, and that it outputs linkedinCompanyURL. Does not cover error cases or rate limits, but adds meaningful context beyond 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?
Description is front-loaded with purpose, includes credit cost, workflow notes, and parameter list. However, it redundantly repeats the purpose phrase. Still concise enough with most sentences earning their 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?
For a simple single-parameter tool with no output schema, the description provides sufficient context: input, output (implicitly LinkedIn URL), workflow position, credit cost, and a hidden field warning. Covers the essential aspects.
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% for the single parameter queryValue. Description simply restates 'Company name column', adding no new semantic meaning or usage examples 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 it finds a LinkedIn company profile from a name, specifically returning the LinkedIn URL. It differentiates from siblings by positioning itself as the entry point for company workflows, before enrich_companies.
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 it is the entry point and should be used before enrich_companies. Also mentions it produces the linkedinCompanyURL needed by find_email, providing chaining guidance. Credit cost is noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import LinkedIn Leads from Target Companies Find leads inside a list of target companies - Select a Google Sheet column with company LinkedIn URLs - Paste a Sales Navigator Lead search URL defining your lead criteria - Get matching leads from those companies Cost: 1 credit(s) per call. Category: import::sales navigator::lead::company
Cross a target company's LinkedIn URL with Sales Navigator criteria. Ideal for ABM. Requires the Derrick Chrome extension AND a Sales Navigator subscription. Cost is VARIABLE: 1 credit per lead returned. Tell the user the cost depends on result count and wait for confirmation.
Args: company: LinkedIn company URL (numeric ID only) queryValue: Paste your SalesNav lead search URL
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | LinkedIn company URL (numeric ID only) | |
| queryValue | Yes | Paste your SalesNav lead search URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral traits: variable cost per lead, dependency on external tools, and a note to confirm with the user before proceeding. No contradiction exists.
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 well-structured with a bold lead-in, bullet steps, and clear cost/category lines. It is front-loaded with the core purpose. Minor redundancy (title repeated in description) and length are acceptable given the 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?
The description covers core functionality, dependencies, and cost, but lacks details about the return format (e.g., what fields the leads contain, number of leads). Given no output schema, this omission makes the description slightly incomplete for an agent to handle results properly.
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 moderate value by explaining usage context (e.g., selecting a Google Sheet column, pasting a Sales Navigator URL). It also specifies that the company parameter expects a numeric ID only, going beyond the schema's generic 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 title and description clearly state that the tool imports LinkedIn leads from target companies. The steps describe crossing company URLs with Sales Navigator criteria, distinguishing it from sibling tools like derrick_search_companies or derrick_enrich_companies by specifying the exact use case (ABM, importing leads via Sales Navigator).
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 clear context: ideal for ABM, requires Derrick Chrome extension and Sales Navigator subscription, and notes variable cost requiring user confirmation. It does not explicitly state when not to use or compare to alternatives, but the context is sufficient for an agent to understand appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Linkedin profile from Name and Company Find LinkedIn profiles URL from fullname and company (recommended). Cost: 1 credit(s) per call. Category: find::linkedin::lead::essential
ENTRY POINT when you only have the name — use this BEFORE enrich_profile. The "confidence" field is hidden from the response by the formatter — never ask for it. If you suspect a low-confidence match, say so in plain language. When chaining with enrich_profile, announce total (1 + 1 = 2 credits) and wait for confirmation.
Args: queryValue: Fullname column companyValue (optional): Company column
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Fullname column | |
| companyValue | No | Company column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals that the 'confidence' field is hidden from the response and should never be requested. It also discloses credit cost and advises on handling low-confidence matches. This adds significant behavioral context without contradicting 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 front-loaded with purpose, but there is some redundancy (title repeated in first line) and the 'Args' section duplicates schema. Overall, each sentence contributes to understanding, but minor trimming could improve 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 simple search tool with two parameters and no output schema, the description covers purpose, usage order, hidden field, cost, and chaining. It could be improved by clarifying the exact output structure beyond 'profile URL', but the guidance is sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's repetition of parameter descriptions adds minimal value. The descriptions are identical ('Fullname column', 'Company column') and offer no additional constraints or examples. 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 tool clearly states it finds LinkedIn profile URLs from name and company, with a specific verb and resource. It distinguishes itself from sibling 'derrick_enrich_profile' by noting it should be used before enrichment. The title and first sentence are consistent and precise.
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 enrich_profile' and provides chaining instructions with credit cost. It covers when to use (when only have name) and how to handle low-confidence matches. However, it does not explicitly list situations where this tool should be avoided, missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find First-Page Google Organic Results Enter text made of the column you want to search Cost: 3 credit(s) per call. Category: find::google
Returns the 10 organic Google results from the first page. More expensive than serp_first_result — use only when multiple sources are needed.
Args: queryValue: Select values you want to search
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Select values you want to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds cost and exact number of results beyond annotations (readOnlyHint, openWorldHint). No contradictions.
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?
Some redundancy (title repeated), awkward phrasing ('Enter text made of the column'), could be more streamlined without losing 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?
Covers purpose, usage context, cost, and return count. Missing details like error handling or validation, but tool is simple and annotations cover read-only nature.
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 significant new parameter meaning beyond 'Select values you want to search'.
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?
Explicitly states it returns the 10 organic Google results from the first page, and distinguishes from sibling tool serp_first_result which returns only one result.
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 'More expensive than serp_first_result — use only when multiple sources are needed', providing clear when-to-use and when-not-to-use guidance with sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find First Google Organic Result Enter text made of the column you want to search Cost: 2 credit(s) per call. Category: find::google
Returns the first organic Google result for a query. Useful for finding a person's website, LinkedIn, etc.
Args: queryValue: Select values you want to search
| Name | Required | Description | Default |
|---|---|---|---|
| queryValue | Yes | Select values you want to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds that it costs 2 credits per call and returns the first organic result, providing useful behavioral context beyond the 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?
Description is concise with a clear title, brief purpose statement, cost, and parameter description. No wasted words, but the structure could be more front-loaded for quick scanning.
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 covers purpose, cost, and basic behavior. It lacks explicit error handling or result format details, but is largely 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?
Only one parameter with 100% schema description coverage. The description adds 'Enter text made of the column you want to search' which provides slight additional context, but overall adds limited meaning beyond the schema's 'Select values you want to search'.
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 returns the first organic Google result for a query, with examples of use cases like finding a person's website or LinkedIn. This distinguishes it from sibling tools such as derrick_serp_first_page.
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 it is useful for finding a person's website or LinkedIn, but it does not explicitly compare with alternatives or provide when-not-to-use conditions. Lacks explicit guidance on choosing this over derrick_serp_first_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the Derrick upgrade / subscription flow. Returns a one-click Stripe Checkout URL for the chosen plan.
Workflow:
If the user has named a plan (MINI / STANDARD / PLUS / PRO), call with plan set to that name. Returns a Checkout URL the user clicks to subscribe.
If the user just says "upgrade" without picking a plan, call with no argument. The tool returns the live list of plans with prices and credits — ask the user which one, then re-call with plan set.
ALWAYS call this tool when the user wants to upgrade, go premium, subscribe, or change plan. Do NOT hand out URLs from memory.
Triggers (any language): "upgrade", "go premium", "subscribe", "change plan", "unlock API", "passer premium", "souscrire", "changer de plan".
Always reply in the user's language and tone.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Plan name: MINI, STANDARD, PLUS, or PRO. Omit to fetch the live plan list first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-step behavior (plan list retrieval vs. immediate URL), confirms non-destructive nature via annotations, and adds context about invoking based on user input. No contradiction with 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?
Front-loaded with purpose, followed by structured workflow, triggers, and note on language adaptation. Every sentence is necessary and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects of the tool: input variants, output (URL or plan list), and usage rules. No missing information for a tool with one optional parameter and 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?
Single parameter 'plan' is fully described in schema and description. The description adds meaningful context: when to include vs. omit to trigger different behaviors (return plan list vs. checkout URL). Schema coverage is 100%.
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 starts the upgrade/subscription flow and returns a Stripe Checkout URL. It distinguishes from siblings like derrick_account or derrick_credits by focusing on the upgrade action.
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 explicit workflow: call with plan if user specifies one, otherwise call without plan to get list of plans. States to always use this tool for upgrade requests and not to hand out URLs from memory. Lists multilingual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify Email Check if an email address is valid. Cost: 1 credit(s) per call. Category: clean::Lead
Returns a certainty level: ultra_sure, sure, risky, invalid, not_found. Charged 1 credit per call EVEN IF not_found.
Args: email: Choose email column
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Choose email column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds concrete behavioral details: cost of 1 credit per call, charged even if the email is not found, and the specific return levels (ultra_sure, sure, risky, invalid, not_found). This significantly enhances transparency beyond 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 short and mostly focused, but includes a redundant title line. Every sentence adds information (purpose, cost, return values), though the structure could be slightly tighter.
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 verification tool with no output schema, the description adequately covers return values, cost, and behavior. However, it lacks usage context and does not explain the meaning of the return levels, leaving some 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% with a single required 'email' parameter. The description's 'Choose email column' adds no extra semantics or format guidance beyond the schema. Baseline 3 is appropriate for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if an email address is valid' and lists the return certainty levels. It uses a specific verb 'verify' on a specific resource 'email', and while sibling tools exist (e.g., derrick_find_email), the action of verification is distinct.
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. The description mentions cost and charging even for not_found, which is a soft usage hint but does not compare to sibling tools or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich Website with Emails, Phones & Social Profiles Extracts emails, phone numbers, and social media links from a website. Cost: 2 credit(s) per call. Category: enrich::Company
Scrapes public emails, phone, and social media links from a website. Emails are usually GENERIC (contact@, hello@) — for a specific person's email use find_email. Charged 2 credits even if no contacts are found.
Args: website_url: Enter a full website URL (e.g., example.com)
| Name | Required | Description | Default |
|---|---|---|---|
| website_url | Yes | Enter a full website URL (e.g., example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it scrapes public data, costs 2 credits regardless of results, and that emails are generic. Annotations already indicate read-only and open-world; description adds useful context beyond 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?
Reasonably concise with clear sections (purpose, cost, category, usage advice). Slight repetition between first and third sentences but overall well-structured 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?
Covers what is extracted (emails, phones, social), generic email behavior, cost, and condition (charged even if no contacts). No output schema but sufficient for a simple enrichment 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?
Only one parameter (website_url) with 100% schema coverage. The description repeats the schema example exactly, adding no new semantic meaning. Acceptable but no added 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 extracts emails, phones, and social profiles from a website, with a specific verb 'Enrich' and resource 'Website'. It distinguishes from sibling 'find_email' by noting generic vs specific emails.
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 explicit guidance: use this for generic contacts, and use 'find_email' for specific persons. Also mentions cost and charging even if no contacts found. Could mention alternatives for phone/social but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1derrick_accountderrick_configurederrick_creditsderrick_data_gouvderrick_enrich_companiesderrick_enrich_profilederrick_find_emailderrick_find_genderderrick_find_phonederrick_find_techderrick_get_name_from_emailderrick_helpderrick_linkedin_profile_followers_countderrick_push_to_lgmderrick_search_companiesderrick_search_leads_in_companiesderrick_search_linkedin_profilederrick_serp_first_pagederrick_serp_first_resultderrick_upgradederrick_verify_emailderrick_website_contact_socialMost tools have clearly distinct purposes, but a few overlap (e.g., find_email vs website_contact_social both extract emails, though from different sources; enrich_profile vs follower count both enrich profiles). Descriptions are detailed enough to usually disambiguate.
All tools follow the 'derrick_' prefix with snake_case and a consistent verb_noun or verb_preposition_noun pattern (e.g., search_companies, find_email, configure, help). No mixing of conventions.
22 tools is slightly above the ideal range but justified by the breadth of functionality (account, enrichment, search, verification, push, help, upgrade). No redundant tools, each adds value.
The tool set covers a wide range of sales intelligence needs: company and profile enrichment, email/phone finding, website extraction, SERP search, verification, and account management. Minor gaps like absence of a bulk operation tool or a direct delete tool are acceptable given the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DerrickAppOrg/derrick-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
