Sign yourself up for a developer key without leaving MCP. The email is contact and recovery, not a wall. One key per email, free tier (100 checks a month); the key is in this response and never shown again. Nothing on knowngate.com itself needs a key.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | Who is signing up, e.g. your product name | |
| contact_email | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses several behaviors beyond the spare annotations: one key per email, 100 checks/month free tier, the key appears exactly once and is never shown again, and email is used only for contact/recovery. These are meaningful operational facts that help the agent reason about side effects. The annotations (readOnly=false, idempotent=false) are consistent with this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with distinct value: the action, email purpose, key uniqueness/quota/delivery, and the website exception. The purpose is front-loaded and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description appropriately states that the key is in the response and shown only once. It also covers the free-tier limit and usage scope. The only notable gap is the behavior on duplicate registration (e.g., whether it errors or returns the existing key), which is ambiguous despite the 'one key per email' note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: agent_name has a description but contact_email has only format/pattern constraints. The description fills the email gap by clarifying its purpose ('contact and recovery, not a wall') and the one-key-per-email constraint. It adds no new information about agent_name, but the schema already covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sign yourself up for a developer key'. This clearly distinguishes the tool from the sibling check_* tools, which are all lookup/inspection operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when the key is needed ('without leaving MCP') and when it isn't ('Nothing on knowngate.com itself needs a key'). It also conveys the free-tier/quota context. However, it does not explicitly name alternative tools or list exclusion conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The three check tools target clearly different scopes: a single item, a multi-item plan, and a venue-wide chart. register is a distinct action for obtaining a credential. There is no realistic ambiguity between them.
The check_* prefix gives strong pattern consistency across the core operations, and register is a clear verb. It deviates only by not following the check_ prefix, but this is easily understood because it serves a different purpose.
Four tools is appropriately scoped for a focused food-safety checking server. Each tool performs a distinct function with no redundancy, and register is a necessary companion to the three check operations.
The core workflows of checking an item, a plan, and a venue are fully covered, along with developer key registration. Minor gaps exist around inspecting or managing the household premise/restrictions and recovering a lost API key, but they do not block the main checking workflow.