Skip to main content
Glama
DerrickAppOrg

Derrick App

Official
by DerrickAppOrg
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Server Quality Checklist

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

  • Latest release: v0.2.1

  • Disambiguation4/5

    Most 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.

    Naming Consistency5/5

    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.

    Tool Count4/5

    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.

    Completeness4/5

    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.

  • Average 4/5 across 22 of 22 tools scored. Lowest: 2/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 1 commit in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior1/5

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

    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.

    Conciseness2/5

    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.

    Completeness2/5

    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.

    Parameters3/5

    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.

    Purpose2/5

    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.

    Usage Guidelines2/5

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

    No guidance is provided on when to use this tool versus 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.

  • Behavior2/5

    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.

    Conciseness5/5

    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.

    Completeness3/5

    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.

    Parameters4/5

    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.

    Purpose5/5

    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.

    Usage Guidelines2/5

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

    No guidance is provided on when to use this tool versus alternatives, 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.

  • Behavior3/5

    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.

    Conciseness3/5

    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.

    Completeness3/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines3/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose4/5

    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.

    Usage Guidelines3/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines2/5

    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.

  • Behavior4/5

    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.

    Conciseness3/5

    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.

    Completeness4/5

    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.

    Parameters4/5

    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.

    Purpose5/5

    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.

    Usage Guidelines2/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines3/5

    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.

  • Behavior4/5

    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.

    Conciseness5/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines3/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose4/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness5/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness3/5

    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.

    Parameters4/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness3/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior3/5

    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.

    Conciseness5/5

    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.

    Completeness5/5

    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.

    Parameters4/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior5/5

    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.

    Conciseness4/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior4/5

    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.

    Conciseness5/5

    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.

    Completeness4/5

    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.

    Parameters4/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior5/5

    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.

    Conciseness4/5

    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.

    Completeness3/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior4/5

    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.

    Conciseness4/5

    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.

    Completeness5/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior5/5

    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.

    Conciseness5/5

    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.

    Completeness5/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

  • Behavior5/5

    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.

    Conciseness5/5

    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.

    Completeness5/5

    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.

    Parameters5/5

    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.

    Purpose5/5

    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.

    Usage Guidelines5/5

    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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

derrick-mcp MCP server

Copy to your README.md:

Score Badge

derrick-mcp MCP server

Copy to your README.md:

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DerrickAppOrg/derrick-mcp'

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