nerdychefs-mcp
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation5/5
Each tool targets a distinct operation: retrieval by ID, search with filters, random selection, pack browsing, and metadata listing. There is no overlap between get, search, random, or the list variants.
Naming Consistency4/5Almost all tools follow a clear verb_noun pattern (get_, search_, list_, get_), but 'random_prompt' deviates by using an adjective instead of a verb such as 'get_random'. This is a minor inconsistency in an otherwise uniform naming scheme.
Tool Count5/5Eight tools is well-scoped for a prompt discovery and browsing server. Each tool covers a distinct aspect without redundancy, and the count feels neither sparse nor bloated.
Completeness5/5The tool surface fully covers prompt retrieval (by ID, search, random), pack exploration, and reference data (categories, personas, tags). Since the server appears read-only and discovery-focused, there are no obvious missing operations within that stated purpose.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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.
This server has been verified by its author.
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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden alone. It does reveal that results are ordered by commonality, but it doesn't state whether this is a read-only operation, how results are returned, how query and top affect output, or any pagination/limits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. However, the ordering detail is appended without adding much actionable substance, so it is efficient but not information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema and minimal parameter information, this definition is underpowered. It tells the agent why personas are useful, but not what a persona is, how to use the parameters, or what the response contains, leaving a meaningful gap for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of either 'top' or 'query'. An agent cannot know whether 'top' is a count, limit, offset, or ranking threshold, nor what 'query' filters against.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Find personas' for use when filtering prompts, and notes an ordering trait (most common first). It is distinguishable from sibling tools by naming a distinct resource (personas vs prompts, packs, categories, tags), though it doesn't explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when filtering prompts' implies a clear use case, but there is no explicit guidance on when to prefer this tool over alternatives like search_prompts or list_tags. No when-not-to-use or exclusions are provided, leaving some inference to the agent.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'find prompts.' It does not mention what include_prompt_text does, how results are ordered or limited, or what happens when no prompts match. The description reveals little beyond the basic search action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core action plus the main optional filters are front-loaded. It is concise, though slightly under-specified for the number of parameters the tool accepts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no annotations, and no output schema, this one-sentence description is not enough. It omits key usage details such as query requirements, limit behavior, include_prompt_text semantics, and relationship to sibling tools. An agent would need to inspect schemas or guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that category, persona, and tag are filters, but it says nothing about the required query parameter, the limit default/maximum, or the meaning of include_prompt_text. It adds partial value but leaves several parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' with the resource 'prompts' and names the optional filters (category, persona, tag), which clearly indicates a search/listing operation. It does not explicitly distinguish from siblings like get_prompt or random_prompt, but the name and filter list make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a task, with optional filters' implies this is the right tool for searching with criteria, but the description does not state when to prefer it over get_prompt, random_prompt, or the list_* tools. Usage context is implied rather than explicit.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. 'Open a pack' suggests retrieval, but does not clearly state whether this is read-only, what the response contains, whether any state changes occur, or how 'include its prompts' affects the result. The behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no filler. It front-loads the core purpose and adds the key optional behavior right after, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description is too thin. It omits behavior of the 'include_prompt_text' parameter, expected return structure, and any guidance about when to use this vs. sibling tools. An agent would likely need additional clarification to invoke it correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully explains that 'id' can be a slug or exact title and that prompts can optionally be included. However, it does not explain the distinct 'include_prompt_text' parameter, leaving one of three parameters semantically underexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Open') and resource ('a pack'), and adds addressing details ('by slug or exact title'). It is not a tautology and helps distinguish this from sibling tools like get_prompt or list_packs, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for opening a single pack, optionally pulling in its prompts, which gives some usage context. However, it offers no explicit guidance on when to prefer this over siblings like list_packs, get_prompt, or search_prompts, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the browsing/searching behavior but does not disclose what happens when no parameters are provided, whether query and category can be combined, pagination behavior, or the shape/scope of the returned list. This is a meaningful gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler. The core capability is front-loaded and the sentence earns its place by explaining both browsing modes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool, the description gives a usable overview, but it is not complete: there is no output schema, no statement of return value shape, no mention of how to discover valid categories, and no explicit relationship to sibling tools like list_categories or get_pack. It is adequate but leaves several gaps an agent would need to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for two of the three parameters: 'category' maps to the category field, and 'search their titles and descriptions' explains the query parameter. The limit parameter is not explained in either the schema or the description, though its schema definition includes defaults and bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('browse') and resource ('prompt packs'), and specifies two distinct modes: by category or by searching titles/descriptions. This distinguishes it from siblings like get_pack, which implies retrieving a single pack, though it does not explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when browsing packs by category or searching pack titles/descriptions. However, it provides no explicit guidance about alternatives, such as using search_prompts for prompt-level search or get_pack for a specific pack, leaving some routing to inference.
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?
No annotations are provided, so the description carries the full burden. It discloses a meaningful behavior: results start with the most common tags, which is not inferable from the tool name or schema. It does not, however, describe the return shape, query behavior, or safety aspects beyond the obviously read-only listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the core purpose before adding the ordering detail. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter tool with no output schema and no annotations, the description is thin: it leaves return format and the meaning of 'query' unspecified. An agent could call it with no arguments but may pass 'query' incorrectly because its semantics are not documented anywhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'top' and 'query' parameters. The phrase 'starting with the most common' hints at ordering relevant to 'top', but no parameter is explicitly described, and 'query' remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') with a clear resource ('tags') and a purpose ('to use when filtering prompts'). It also notes the ordering ('starting with the most common'), which distinguishes it from sibling tools like list_categories or list_packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent needs tag suggestions for filtering prompts. It does not explicitly state when not to use it or mention alternatives such as search_prompts or list_categories, leaving the routing mostly to inference.
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?
There are no annotations, so the description carries the burden of disclosing behavior. It clearly states the random-selection behavior and the optional narrowing, but it does not disclose edge cases like no matching prompts, whether repeats are possible, or what exactly is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes: the action, the randomness, and the optional filters are all communicated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter tool this is nearly adequate, but with no output schema or annotations, the description should provide more context about return shape and behavior when no prompt matches the filters. It also does not point to sibling list_* tools as sources for valid filter values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names all three parameters and explains their shared role as narrowing filters, which adds meaning beyond the bare schema. However, it lacks detail on value formats, accepted sources, or combination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pick') and resource ('a random prompt'), making the core purpose clear. The randomness distinguishes it from siblings like get_prompt and search_prompts, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'optionally narrowed by category, persona, or tag' implies when filters should be used, but there is no explicit guidance on when to choose this tool over search_prompts or get_prompt. Usage context is implied rather than stated.
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?
With no annotations, the description bears the burden of conveying behavior. 'List' clearly implies a read-only operation with no destructive side effects, but it does not mention output format, ordering, or what happens when no categories exist. For a zero-parameter tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the essential information without any filler. It is appropriately concise for a simple zero-parameter listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains what the tool returns: prompt categories and their subcategories. It could add a little more context about expected output shape, but the tool's simplicity makes the current description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter meaning because there are none, and the schema already provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: list prompt categories along with their subcategories. It is specific enough to be understood, though it does not explicitly contrast itself with sibling list tools such as list_tags or list_packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this tool when you need the available prompt categories and their subcategories. However, there is no explicit guidance about when not to use it or how it differs from other list-oriented sibling tools.
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?
No annotations are provided, so the description carries the full burden. It discloses that the response includes the full prompt text and the verb 'Get' implies a read-only operation. However, it does not mention error behavior, response structure beyond the text, or any prerequisites, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 13 words that front-loads the action ('Get a prompt'), then specifies the key ('numeric ID') and the result scope ('full prompt text'). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is mostly adequate but not complete. With no output schema, it does not specify whether other prompt metadata is returned or how errors (e.g., nonexistent ID) are surfaced, leaving some agent-relevant details unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the sole 'id' parameter. The description adds no real meaning beyond the schema's integer type — it merely restates 'numeric ID' and provides no constraints, origin, or formatting guidance for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a resource ('prompt'), and the retrieval key ('numeric ID'), while clarifying that the result includes the full prompt text. This distinguishes it clearly from siblings like search_prompts and random_prompt, which imply different lookup modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the correct usage context: when an agent has a numeric prompt ID and needs the full prompt text, rather than searching or fetching a random prompt. It does not explicitly enumerate alternatives or exclusions, but the ID-based retrieval criterion provides clear context.
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
Copy to your README.md:
Score Badge
Copy to your README.md: