Exact checks for developers: email DNS, Supabase RLS, cron, JSON, contrast, time zones, robots.txt
Score is being calculated.
Use when you need to check a live Supabase project rather than migration files: returns a read-only SQL query that reads table RLS settings, grants for anon and authenticated, policies, SECURITY DEFINER functions and storage buckets (never row data) and returns one JSON value. Run it with the user's Supabase SQL Editor or a Supabase MCP execute_sql tool, then pass the JSON to deadbolt_check_supabase_access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it never reads row data, it emits a single JSON value rather than a result set, and it must be executed externally via the Supabase SQL Editor or an execute_sql MCP tool. It stops short of noting practical execution limits (query runtime, result size, required privileges), which keeps it from a 5.
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?
It is front-loaded with the 'Use when' trigger and every clause carries a distinct fact (source of truth, what is read, what is excluded, return shape, how to run it, next tool). The first sentence is long and heavily parenthesized, which slightly hurts scannability, but there is no filler to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no output schema and annotations covering the safety profile, the description supplies everything else an agent needs: why to choose it, what the SQL inspects and does not inspect, that the return is one JSON value, how to execute it, and where to send the result. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies there is nothing to configure — the SQL is generated as-is — and adds the meaningful invocation detail that execution happens outside this tool.
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 states a specific verb and resource ('returns a read-only SQL query') and enumerates exactly what the query covers: RLS settings, anon/authenticated grants, policies, SECURITY DEFINER functions, storage buckets. It also draws the key boundary against the sibling workflow ('rather than migration files'), so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('Use when you need to check a live Supabase project rather than migration files'), the alternative it replaces, and the follow-up routing ('pass the JSON to deadbolt_check_supabase_access'). The agent knows both when to pick this tool and what to do with its output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you write, review or are about to apply Supabase / PostgreSQL migration SQL (CREATE TABLE, RLS, CREATE POLICY, GRANT, views, SECURITY DEFINER functions, storage buckets), or when a user asks whether their Supabase data is exposed, whether RLS is set up right, or why a query returns 42501 permission denied or no rows. Replays the SQL with real Postgres rules and returns, per table, what signed-out (anon) and signed-in (authenticated) users can SELECT/INSERT/UPDATE/DELETE (all rows, own rows, some rows, none, or denied for a missing grant), plus findings with severity and ready-to-run fix SQL: RLS off, policies written but RLS never enabled, using(true) writes, personal columns readable by anyone, views that bypass RLS, SECURITY DEFINER functions anyone can call, user_metadata in policies, public bucket listing, grants missing after the Oct 30 2026 default change. Also accepts the JSON produced by deadbolt_catalog_query for the live database. Deterministic; never connects to any database. Up to 200,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Migration SQL (one or many files concatenated, in order), or the single JSON value returned by the catalog query. | |
| project_created_before_2026_10_30 | No | Only for SQL input. true (default): the project grants new public tables to anon and authenticated automatically (projects created before Oct 30, 2026). false: new tables get no grants unless the SQL grants them (projects created on or after Oct 30, 2026). |
Use when the user asks whether their site (or any public site), or a robots.txt they pasted, blocks ChatGPT, Claude, Google AI, Perplexity or other AI crawlers, whether AI can read or train on their content, or why AI search does not mention their site. Fetches the live robots.txt and reports, for 22 named AI bots in four groups (AI training, AI search, assistants, search engines), which are let in, kept out or partly blocked, plus the site's content-signal preference and fixes. Example: {"url": "example.com"} or {"robots_txt": "User-agent: GPTBot\nDisallow: /"}. Pass robots_txt instead of url to check a draft or pasted file without fetching anything. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Website address or domain, e.g. nytimes.com. Send this or robots_txt. | |
| robots_txt | No | robots.txt text to check instead of fetching a site (a draft or a pasted file, up to 512 KB). Empty means no robots.txt. |
Use when you are about to read a big JSON response, log or export into context, before loading it: returns a compact outline of the structure (keys, types, array lengths, one example per repeated shape) so you can plan a query without spending tokens on the whole document. Repairs the JSON first if needed. Follow with mend_query_json to pull only the values you need. Up to 100,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The JSON (or JSON-ish text). | |
| max_depth | No | How many levels to expand. Default 4. | |
| max_items | No | How many array items to show when items differ. Default 6. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it 'repairs the JSON first if needed,' so malformed input is tolerated, and it discloses the compact output shape that lets the agent reason about token cost. It does not say what happens if repair fails or how the outline is formatted, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, the output contract follows, and the next-step pointer closes it, all in roughly two sentences. The trailing 'Up to 100,000 characters' restates the schema's maxLength and is the one sentence that does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return value, and it does: keys, types, array lengths, and one example per repeated shape. Combined with the repair behavior and the named follow-up tool, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with max_depth, max_items and text all documented inline, so the schema carries parameter meaning. The description adds only the input ceiling ('Up to 100,000 characters'), which duplicates the schema's maxLength constraint rather than explaining how max_depth or max_items affect the outline.
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 states a specific verb and resource: it 'returns a compact outline of the structure (keys, types, array lengths, one example per repeated shape).' That output contract distinguishes it from the sibling mend_query_json, which pulls values rather than summarizing shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when you are about to read a big JSON response, log or export into context, before loading it') and an explicit follow-up ('Follow with mend_query_json to pull only the values you need'). The two-step workflow and the alternative are both named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need specific fields from a JSON document without reading all of it: $.users[0].name, $.items[*].id, $.a.b[-1], $.list[1:3], $..email (recursive). Returns each match with its exact path, type and value. Repairs the JSON first if needed, so broken input still works. Up to 100,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum matches to return. Default 50. | |
| path | Yes | Path such as $.users[*].email, data.items[0], $..id, $.list[-1], $.list[1:3]. | |
| text | Yes | The JSON (or JSON-ish text). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: it repairs malformed input before extracting, returns path/type/value per match, and caps input at 100,000 characters. It leaves the default match cap (50) to the schema and says nothing about zero-match behavior, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the use case, then path syntax, then return shape, then the repair and size caveats — each clause contributes distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return contract and does so adequately ('each match with its exact path, type and value'), plus the auto-repair behavior and input size ceiling. Minor gaps remain: behavior on no matches and whether the 50-match default truncates silently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents text, path and max; the description's path examples duplicate much of the path description, though labeling $.. as 'recursive' adds a small clarifying gloss. The 100,000-character mention simply restates the text maxLength. Baseline 3 is appropriate when the schema carries the detail.
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?
States a specific verb+resource ('Extract values from JSON by path') and backs it with concrete path examples ($.users[0].name, $..email, $.list[1:3]), so the operation is unambiguous. It does not name the adjacent siblings (mend_outline_json, mend_check_json, mend_repair_json), so the routing signal is implied by 'without reading all of it' rather than stated.
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?
'Use when you need specific fields from a JSON document without reading all of it' gives a clear triggering condition and implicitly contrasts with dumping the whole document. It stops short of explicit when-not-to or naming the sibling tools that handle structure/validation instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when JSON from an LLM, API, log, config or copy-paste fails to parse (JSON.parse error, "Unexpected token", "Expecting property name"), or the user pastes JSON with trailing commas, single quotes, unquoted keys, comments, Python True/False/None, NaN, missing commas or brackets, a ```json fence, text around it, or output that was cut off. Deterministic repair: returns valid, formatted JSON plus a list of every fix with line and column. Values are never rewritten, so big numbers, number formatting and key order stay exactly as written. If the text is already valid it says so. Up to 100,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The broken JSON, or any text that contains JSON (a chat reply, a log line, a code block). | |
| indent | No | Spaces per indent level in the output. Default 2. Use 0 for one minified line. | |
| sort_keys | No | Sort object keys alphabetically. Default false (keep the original order). |
Use when you need to convert a specific wall-clock time from one place to others, for any date. It uses the real tz database, so daylight saving is right for that exact date (the US and Europe switch on different weeks), and it warns when the time does not exist (spring forward) or happens twice (fall back). Time accepts "15:00", "3:30pm", "noon", "now" or an ISO local time like 2026-11-05T15:00 (no Z). Date defaults to today in the source zone. Returns {input, utc, source:{...}, converted:[{place, zone, local, time_12h, date, utc_offset, abbreviation, day_note, hours_ahead_of_source}], warning?, summary, open_url}.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination places, e.g. ["London","Tokyo"]. | |
| date | No | Optional date YYYY-MM-DD in the source zone. Default today. | |
| from | Yes | Source place or zone, e.g. "New York" or "America/New_York". | |
| time | Yes | Local time in the source place, e.g. "15:00", "3:30pm", "noon", "now", "2026-11-05T15:00". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, but the description adds real behavioral substance: tz-database backing, DST edge cases at the spring-forward/fall-back boundaries, and an explicit warning on non-existent or ambiguous times. It also discloses the exact return shape including the optional 'warning' field, which no annotation or output schema covers here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a 'Use when' clause, and every sentence carries information, including the return-shape contract. The single dense paragraph makes the return-structure sentence slow to parse, which is the one structural cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the response object's fields, including the conditional 'warning' and 'day_note'. For a four-parameter, read-only conversion tool this leaves nothing an agent needs unknown before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already lists most accepted time formats, so the description's value is partly repetition. It does add genuine meaning: the 'no Z' constraint on ISO input and the clarification that the date default is 'today in the source zone' rather than UTC today.
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?
States a specific verb and resource ('convert a specific wall-clock time from one place to others') with an explicit scope qualifier ('for any date'). The contrast with meridian_now and meridian_meeting_slots is implicit but unmistakable, since this is the only tool framed around converting an arbitrary given wall-clock time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The leading 'Use when you need to convert a specific wall-clock time' gives clear triggering context, and 'for any date' rules out a now-only read. It never names an alternative or an exclusion, so an agent must infer when meridian_zone_info or meridian_meeting_slots would be the better pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need to schedule a call across several places. Scans the day in 15-minute steps and ranks start times so the most people are inside working hours and nobody is at night, using each place's real offset and DST for that date. Returns up to 5 slots with each person's local start and end, and says plainly when no time works for everyone. Defaults: working hours 9 to 17, 60 minutes, date today in the first place.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date YYYY-MM-DD, local to the first place. Default today. | |
| count | No | How many slots to return, default 5. | |
| places | Yes | Where each attendee is, e.g. ["San Francisco","London","Tokyo"]. | |
| end_hour | No | Working day end hour, default 17. | |
| start_hour | No | Working day start hour, default 9. | |
| duration_minutes | No | Meeting length in minutes, multiple of 15. Default 60. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the 15-minute scan granularity, the ranking heuristic (maximize people in working hours, avoid night), DST-correct offsets per date, the return shape (up to 5 slots with local start and end per person), and the explicit no-feasible-time message. This is exactly the behavioral disclosure an agent needs.
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 tight sentences, front-loaded with the usage trigger, then mechanics, then return behavior, then defaults. No sentence is redundant and no padding or hedging appears.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter read-only tool with no output schema, the description covers input defaults, ranking logic, return payload, and the empty-result case. Nothing an agent needs in order to call it correctly or interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter and its default. The description restates the defaults (9–17 working hours, 60 minutes, date today in the first place) and the count of returned slots, but adds little meaning beyond what the schema fields already state, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('scheduling a call across several places') and immediately conveys the function as cross-time-zone slot finding, which is distinct from the sibling conversion tools (meridian_convert_time, meridian_now, meridian_zone_info). An agent can select it without opening the schema.
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?
Opens with an explicit when-to-use trigger ('Use when you need to schedule a call across several places'), giving clear invocation context. It does not name alternatives or exclusion conditions (e.g., use meridian_convert_time when you only need a point-in-time conversion), so it stops 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.
Use when the user asks what time or date it is right now somewhere. Reads the server clock and returns the current time, date, UTC offset, abbreviation and daylight saving status for each place. Places can be cities ("Tokyo"), IANA zones ("Europe/Paris"), abbreviations ("PST") or "UTC+5:30".
| Name | Required | Description | Default |
|---|---|---|---|
| places | Yes | Cities, IANA zones or abbreviations, e.g. ["London","Asia/Tokyo"]. |
Use when you need to answer "what is the UTC offset of X", "does X observe daylight saving" and "when do the clocks change". Returns the current offset and abbreviation, whether the place observes DST, every clock change in the year with exact local before and after times, and the next change. Abbreviations like IST or CST are ambiguous, so the answer says which zone was used.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to list clock changes for. Default this year. | |
| place | Yes | City, IANA zone or abbreviation, e.g. "London" or "America/Phoenix". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the description's job is to add return-shape context. It does that well: current offset, abbreviation, DST observance, all clock changes in the year with local before/after times, and the next change. The ambiguity note about IST/CST and disclosure of which zone was resolved is genuinely useful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the use case, then the return contents, then the ambiguity caveat — a logical order with no filler. The middle sentence is long but each clause maps to a distinct returned field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so field by field, and annotations cover the safety profile. It stops short of describing error behavior for unresolvable places or out-of-range years, which is the only meaningful gap for a two-parameter lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema, and the description adds only a little: it implies `place` tolerates abbreviations and that `year` scopes the clock-change listing. It adds no format or edge-case detail (e.g. what happens with an ambiguous abbreviation or a year with no DST) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (zone offset/abbreviation/DST/clock changes) and enumerates exactly what is returned, including the next change. It is clear enough to separate from generic time tools, though it never names the sibling tools (meridian_now, meridian_convert_time) it should be distinguished from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit triggering questions ("what is the UTC offset of X", "does X observe daylight saving", "when do the clocks change"), which is strong when-to-use guidance. It lacks any when-not-to-use or named alternative, so an agent must infer the boundary against meridian_convert_time and meridian_now.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you or the user are about to publish or edit an SPF, DMARC or DKIM TXT record, for example after writing a new SPF record that adds a sending service, or when the user pastes a record and asks "is this right?". Detects the record type. SPF: syntax per RFC 7208, every include and redirect followed live in DNS and counted against the 10-lookup limit, void lookups, loops, the final all; returns a lookup tree. DMARC: RFC 7489 tags and values (p, sp, pct, rua/ruf, adkim/aspf, fo). DKIM: key type and RSA key size read from the key, revoked (empty p=) or truncated keys. Returns valid true/false, errors, warnings and where to publish it. Pass domain so a/mx terms without a value can be resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional: the domain the record is for, so SPF a and mx terms can be checked. | |
| record | Yes | The TXT record value, e.g. "v=spf1 include:_spf.google.com ~all" or "v=DMARC1; p=none; rua=mailto:dmarc@mycompany.com". Quoted chunks ("..." "...") are joined. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly spends its space on behavior instead: it performs live DNS lookups, follows every include and redirect, counts them against the 10-lookup limit, and reports void lookups and loops, plus what is returned (valid true/false, errors, warnings, publish location). That is valuable context an agent could not get from the annotations. It does not discuss latency or failure behavior when DNS is unreachable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded: the usage trigger comes first, then the per-record-type capabilities, then the return shape. Each sentence is informative, though the enumeration of DMARC tags (p, sp, pct, rua/ruf, adkim/aspf, fo) is slightly listy. Overall the density is justified for a validating tool with three distinct validation modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of describing returns, and it does: valid true/false, errors, warnings, and where to publish. It also explains the three validation modes, the live-DNS lookup behavior, and the one non-obvious parameter. Nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, giving a baseline of 3. The description restates the domain parameter's purpose, adding only the nuance that it lets a/mx terms without a value be resolved; that is a small increment over the schema's own wording. It adds nothing about the record parameter beyond what the schema example already shows.
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 states a specific verb and resource: it checks SPF, DMARC and DKIM TXT records, auto-detects the type, and validates them per RFC 7208/7489. This distinguishes it from the sibling stamp_check_email_domain implicitly, because this tool's input is a single record rather than a domain. However, the sibling is never named, so the agent has to infer that split from the parameter shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear trigger conditions: when you or the user are about to publish or edit a record, after adding a sending service, or when a pasted record prompts 'is this right?'. That is concrete and actionable. It does not name when-not to use it or point to stamp_check_email_domain as the alternative for whole-domain checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks why their email goes to spam, whether their domain is set up to send email, or before they launch a newsletter, cold outreach, transactional email or a new sending service, e.g. "why are my emails going to spam?", "is my SPF/DKIM/DMARC right?", "do I meet Gmail and Yahoo's sender requirements?" or "I added SendGrid, did I break SPF?". Reads public DNS (DNS-over-HTTPS) and checks: SPF (exactly one record, every include followed and DNS lookups counted per RFC 7208 against the limit of 10, void lookups, loops, +all/?all, ptr), DMARC (RFC 7489 syntax, policy, pct, alignment, inherited from the parent domain, and whether an external report address authorized it), DKIM (17 common selectors plus any you pass; key type and RSA key size read from the key, revoked or broken keys), and MX (provider, null MX). Returns a grade A-F, a verdict, each check with status pass/warn/fail/info, whether the Gmail, Yahoo and Outlook.com sender rules are met, and copy-ready DNS records to fix problems (e.g. one merged SPF record, a starter DMARC record). DNS cannot list DKIM selectors, so when none of the common selectors is found the result says so and a known selector (the s= value in a DKIM-Signature header) can be passed in. Accepts a domain, an email address or a URL. Results are cached for 5 minutes; pass fresh=true right after the user changes DNS.
| Name | Required | Description | Default |
|---|---|---|---|
| fresh | No | true to skip the 5-minute cache, e.g. right after a DNS change. | |
| domain | Yes | The sending domain, e.g. mycompany.com. An email address (you@mycompany.com) or a URL also works. | |
| dkim_selectors | No | Extra DKIM selectors to try besides the common ones, e.g. ["mxvault"]. Find it as s= in a DKIM-Signature header or in the provider's setup page. |
Use when the user asks whether a color combination is readable or accessible, passes WCAG AA or AAA, or has enough contrast (text on a background, button, badge, link color), or what a color is in another format. Returns the exact contrast ratio, pass or fail for normal text, large text and UI components at AA and AAA, the APCA lightness contrast and a plain note. Colors can be hex, rgb(), hsl() or CSS names. Example: {"foreground": "#777777", "background": "#ffffff"}. Also returns each color in hex, rgb, hsl and oklch with its nearest CSS name.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Background color, e.g. "#ffffff". | |
| foreground | Yes | Text (or icon) color, e.g. "#767676" or "rgb(20 20 20)" or "tomato". |
Use when the user has a whole design system, theme or stylesheet and wants every text and background pair checked for accessibility in one go. Takes up to 50 pairs and returns the ratio and AA and AAA results for each, with a count of failures. Example: {"pairs": [{"foreground": "#777", "background": "#fff", "label": "muted text"}, {"foreground": "#fff", "background": "#ff5a1f", "label": "button"}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| pairs | Yes | Pairs to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real value beyond that: the 50-pair cap, the returned fields (ratio, AA/AAA results), and a failure count, which tells the agent what to expect from a call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the when-to-use condition, then the behavior, then a compact example. Every sentence carries information; the example is slightly long but directly useful for constructing the nested array.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the return shape (ratio plus AA/AAA per pair and a failure count), and the input is fully covered by schema plus example. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns above that by supplying a concrete example payload showing foreground/background/label usage and restating the 50-pair limit. It adds practical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (check contrast for many color pairs at once) and scopes it to batch/design-system use, which cleanly separates it from the single-pair sibling swatch_check_contrast. An agent can pick it without opening the schema.
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?
Gives a clear triggering condition (user has a design system, theme, or stylesheet and wants every pair checked in one go), which implicitly routes batch work here rather than to the single-pair tool. It stops short of explicitly naming swatch_check_contrast as the alternative for one-off checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a color pair fails contrast and the user wants the smallest change that makes it pass, such as "make this gray text accessible without changing the look". Returns the closest text color on that background that reaches the target (AA, AAA, AA-large or ui), and separately the closest background, keeping the hue. Example: {"foreground": "#777777", "background": "#ffffff", "target": "AA"}. Returns already_passes if nothing needs to change.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Contrast target. Default AA. | |
| background | Yes | Current background color. | |
| foreground | Yes | Current text color. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description focuses appropriately on behavior beyond safety. It adds useful return context: the closest text color on the background, separately the closest background while keeping hue, and an already_passes outcome when no change is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the usage condition, then explains the return behavior, provides a compact example, and notes the already_passes case. Every sentence contributes to selecting or correctly invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description sufficiently explains what the tool returns and how the already_passes case works. Combined with full parameter documentation in the schema and the safety annotations, an agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the three parameters and the target enum. The description reinforces this with an example and mentions target values, but it does not add syntax or semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: find the closest accessible text or background color that passes a contrast target. It also distinguishes the scenario from mere checking by saying it is for when a color pair fails contrast and the user wants the smallest change that makes it pass.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition: use when a color pair fails contrast and the user wants the smallest change that makes it pass. However, it does not explicitly name alternatives such as swatch_check_contrast or swatch_pick_text_color, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks for a palette, shades, tints, a design-token scale or a Tailwind-style 50 to 950 ramp from a brand color. Returns 11 steps that keep the hue, with the hex, contrast on white and on black, and the best text color for each step. Example: {"color": "#ff5a1f", "name": "brand"}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Token name used in the CSS and Tailwind output. Default "brand". | |
| color | Yes | Base color, e.g. "#ff5a1f". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns credit for adding return composition: 11 steps, hue preserved, hex plus contrast on white and black plus recommended text color per step — meaningful since no output schema exists. It could still note determinism or that the base color is echoed as one of the steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: trigger conditions first, output shape second, example last. Every sentence carries information an agent needs and nothing is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only, no-output-schema tool, the description supplies the trigger context, the full return content, and a working example. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description goes beyond by supplying a concrete invocation example with both parameters populated ({"color": "#ff5a1f", "name": "brand"}), which shows the optional name in context. It does not explain format tolerance (hex vs named colors) beyond the schema's own example.
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?
States a specific verb (build) and resource (a 50-950 color palette / 11-step ramp) from a single base color, immediately separating it from siblings like swatch_check_contrast or swatch_convert_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause enumerates concrete user intents ('palette, shades, tints, a design-token scale or a Tailwind-style 50 to 950 ramp') that should trigger this tool, which is strong routing guidance. It stops short of naming the sibling tools or stating when NOT to use it (e.g. single-pair checks belong to swatch_check_pairs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need a yes/no on whether a cron expression would fire at a specific instant in a timezone — for example before shipping a schedule that crosses a DST transition, or to verify a single expected fire. Example: {"expression":"0 9 * * 1-5","timezone":"America/New_York","at":"2026-11-06T14:00:00Z"}. Returns fires true/false, the local wall time of that instant, and DST notes if the local time is in a gap or fold.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | ISO datetime to test, e.g. 2026-11-06T14:00:00Z. | |
| timezone | No | IANA timezone. Default UTC. | |
| expression | Yes | Cron expression (5 or 6 fields, or a nickname like @hourly). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description goes beyond that by disclosing the return payload — boolean fires, the local wall time, and DST gap/fold notes — which is meaningful since no output schema exists. It says nothing about invalid-expression error behavior, so it stops short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'Use when...', then a concrete example, then the return shape — a tight three-move structure with no filler. The example datetime repeats the schema's own example string, a minor redundancy, but the full call with all three parameters still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter, read-only predicate tool with no output schema, the description covers purpose, triggering scenarios, a full example call, and the return values including DST edge-case output. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents expression, at, and timezone including formats and defaults. The worked example adds a composite call pattern but no syntax or constraint detail beyond what the schema already states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: a yes/no check of whether a cron expression fires at a specific instant in a timezone. It is clearly distinguishable in intent from a next-runs lister, though it never names that sibling explicitly.
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?
Gives concrete when-to-use scenarios: validating a schedule that crosses a DST transition before shipping it, or confirming a single expected fire. It implies the single-instant use case vs listing upcoming runs, but does not state an explicit exclusion or name the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you or the user just wrote a cron expression (GitHub Actions, Vercel cron, Cloudflare Cron Triggers, systemd, an agent schedule) and need its next fire times. Pass the expression and an IANA timezone (default UTC). Returns the next N runs as local wall times and UTC ISO, a plain-English field breakdown, and DST gap/fold warnings (spring-forward skips, fall-back double fires). Example: {"expression":"0 9 * * 1-5","timezone":"America/New_York","count":5}. Uses the tz database, so DST rules match the region and year. Not for converting a meeting time across cities (use Meridian) or for email DNS (use Stamp).
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Optional ISO datetime to start from (default now), e.g. 2026-03-07T12:00:00Z. | |
| count | No | How many next runs to return (1–20). Default 5. | |
| timezone | No | IANA timezone for local wall times, e.g. America/New_York. Default UTC. | |
| expression | Yes | Cron expression: 5 fields (minute hour day-of-month month day-of-week) or 6 with seconds first. Also accepts @hourly, @daily, @weekly, @monthly, @yearly. |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deadbolt_catalog_querydeadbolt_check_supabase_accessdoorman_check_ai_bot_accessmend_outline_jsonmend_query_jsonmend_repair_jsonmeridian_convert_timemeridian_meeting_slotsmeridian_nowmeridian_zone_infostamp_check_dns_recordstamp_check_email_domainswatch_check_contrastswatch_check_pairsswatch_fix_contrastswatch_make_scaletick_matchestick_next_runsDNS, TLS, HTTP and SEO checks, plus stateful change watches that diff a page over time.
Exact tools for AI assistants: QR codes, word counts, text diff and JSON checks. Free, no account.
Outside-in DNS, email security, SEO, GEO and app-link checks plus developer utilities.
SEO, broken links, Lighthouse, sitemaps, Open Graph tags and SSL expiry for any list of URLs.
Add one secure layer between your agents and this server.