49 free agent tools: WHOIS, PDF to text, email checks, FX rates, X12 EDI, JSON repair. No API key.
Parses a standard 5-field cron expression (or 6-field with leading seconds, or a macro like @daily), validates it, describes it in plain English, and computes the next run times in a given timezone with daylight-saving handled. Use it before writing a schedule to config — cron's day-of-month/day-of-week OR-semantics and step syntax are a common source of silently wrong schedules.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Compute run times after this instant instead of now. | now |
| count | No | How many upcoming run times to return. | |
| timezone | No | IANA timezone the schedule runs in. | UTC |
| expression | Yes | Cron expression, e.g. "*/15 * * * *", "0 9 * * 1-5", "@daily". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already make safety transparent (readOnlyHint, idempotentHint, destructiveHint=false), so the description correctly avoids repeating them. It adds meaningful behavior beyond annotations: supported expression formats, macro support, plain-English explanation, timezone-aware calculations with DST handling, and next-run computation. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core function, and includes a practical motivating use case in the second sentence. Every sentence earns its place, and there is no filler or repetition of schema or annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The overall tool context is well covered for an agent: it knows this is a read-only, idempotent validation/explanation/computation tool, and it knows what expressions are accepted and what result is produced. There is no output schema for the exact structure of the English explanation and run times, but the title and description communicate the main returned concept sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 4 parameters at 100% coverage, so the description is not required to re-document them. The schema itself handles parameter meaning well. The description adds no significant parameter-level detail, which is appropriate given full schema coverage. A baseline 3 is correct.
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 names a clear verb-and-resource combination: parses, validates, describes, and computes next run times for a cron expression. It also explicitly distinguishes its semantics from generic time or JSON tools among the siblings, making its scope unmistakable.
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 a strong, explicit usage cue: use this before writing a schedule to config. It also explains why (day-of-month and day-of-week OR semantics and step syntax cause silent errors). It does not name a specific alternative sibling, but no sibling directly competes with this tool, so the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts a document to markdown or plain text: pass a public URL or the file itself as base64, and get back the content with headings, tables and lists preserved, at a fraction of the tokens that rendered pages cost. Use it when a harness has no native reader for the format — .docx, .xlsx, .odt and .numbers rarely have one — when a document is only a URL away, or when a long PDF's text matters and its layout does not. Handles PDF (.pdf), Word (.docx), Excel (.xlsx, .xlsm, .xlsb, .xls), OpenDocument (.odt, .ods), Apple Numbers, CSV, HTML, XML, and plain-text formats such as .txt and .md. The format is detected from magic bytes, not trusted from the file name, so a PDF served from a .php URL still converts. Two honest limits: a scanned PDF with no text layer has nothing to extract (this is conversion, not OCR), and legacy binary .doc and .ppt files are not readable — resave them as .docx or .pptx. Images are refused rather than described. Documents up to 10 MB.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public URL of the document to fetch and convert. | |
| base64 | No | The file content as base64 (or a data: URI) instead of a URL, for documents not publicly reachable. Up to 10 MB decoded. | |
| format | No | Output style: markdown keeps headings, tables and lists; text strips them. | markdown |
| filename | No | Original file name, e.g. "report.docx". Only needed when the format cannot be detected from the URL or the bytes. | |
| max_chars | No | Truncate the extracted content beyond this many characters. | |
| timeout_ms | No | Fetch timeout in milliseconds when url is used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. On top of that, the description adds valuable behavioral detail: format detection via magic bytes rather than filename, the 10 MB limit, no OCR capability, and refusal to describe images. This goes well beyond the annotations and gives an agent realistic expectations.
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 longer than average but justifies its length by covering supported formats, use cases, detection behavior, and limits. The core action is front-loaded in the first sentence, and every subsequent clause adds practical information rather than 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 six optional parameters, no output schema, and a broad format list, the description supplies what an agent needs: supported formats, input modes, output style semantics, size limits, and failure cases. The return content is adequately described as extracted markdown or plain text, which is sufficient for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all six parameters. The description adds meaning beyond the schema by explaining that markdown preserves structure while text strips it, that base64 covers non-public documents, and that filename is only needed when detection fails. This is a meaningful enrichment beyond the baseline.
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 uses a specific verb and resource: 'Converts a document to markdown or plain text', and further specifies inputs (public URL or base64) and output characteristics (headings, tables, lists preserved). It clearly differentiates from sibling tools, none of which perform document extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use it when a harness has no native reader for the format... when a document is only a URL away, or when a long PDF's text matters and its layout does not.' It also states exclusions: scanned PDFs without a text layer, legacy binary .doc/.ppt files, and images are not handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers the questions WHOIS used to answer, over RDAP — the structured protocol the registries themselves now serve — with no key and no scraping: who registered a domain, when it expires, which registrar and nameservers it uses, whether transfers are locked, and whether DNSSEC is signed. Give it an IP address instead and it returns the owning network: name, CIDR range, and the responsible registry. A domain that does not resolve in RDAP is reported as likely available to register — an answer, not an error. These are live registry facts that no training corpus can supply: registrations, expiries and transfers happen daily, and an agent that guesses at them guesses wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Domain name or IP address to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world behavior, and the description adds meaningful context beyond them: uses RDAP with no key and no scraping, non-resolving domains are reported as 'likely available' rather than errors, and results are live registry facts rather than static knowledge. This substantially enriches the agent's expectation model. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than strictly necessary but front-loads the core purpose and protocol before enumerating outputs. Each sentence contributes something: protocol provenance, input variants, edge-case behavior, and the live-data rationale. It is slightly verbose but well structured and readable.
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 single-parameter lookup with no output schema, the description covers input variants, output fields for both domain and IP, edge behavior for unresolved domains, and the fact that no key or scraping is required. An agent has sufficient information to decide when to use it and what to expect from the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 'query' fully with type, maxLength, example, and description coverage of 100%, so the baseline is 3. The description adds useful semantic detail: an IP input returns the owning network with name, CIDR range, and registry, while a non-resolving domain returns a likely-available status.
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 identifies a precise action: resolve a domain or IP via RDAP to retrieve registration details, expiry, registrar, nameservers, status, DNSSEC, or owning network. It clearly differentiates this tool from all listed siblings, none of which handle domain or IP lookups. The title also reinforces the specific resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the two supported input modes—domain and IP—and what each returns, giving an agent strong context for when the tool applies. It does not name alternative tools or explicit when-not-to-use conditions, but no sibling tool overlaps with this functionality, so exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiles structured JSON into standards-valid X12. The parts that get documents rejected are exactly the parts a language model cannot hold in its head: the 856 hierarchy needs sequential HL IDs where every level names its parent's ID, and on a multi-carton, multi-SKU shipment that bookkeeping goes wrong silently. The ISA header is fixed-width — 106 characters exactly, every element space-padded to size — and one character out crashes the receiver's translator. Segment counts in SE01, CTT01, GE01 and IEA01 must agree with what was actually emitted. All of that is computed here rather than written by hand.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Document content. For 856: {shipment_id, ship_date, orders:[{po_number, packs:[{sscc, items:[{upc, quantity, unit}]}]}], parties:[{role,name,id}]}. For 850: {po_number, order_date, lines:[{quantity, unit, unit_price, upc, description}], parties:[...]}. | |
| document | No | Transaction set to build. | 856 |
| sender_id | No | ISA06 sender identifier. | SENDER |
| timestamp | No | ISO instant for the envelope date/time. Defaults to now. | |
| receiver_id | No | ISA08 receiver identifier. | RECEIVER |
| control_number | No | Interchange control number (ISA13). Also seeds GS06 and ST02. | |
| test_indicator | No | Mark the interchange as test (ISA15 = T) rather than production (P). | |
| include_envelope | No | Wrap the transaction set in ISA/GS ... GE/IEA. | |
| sender_qualifier | No | ISA05 qualifier, e.g. ZZ, 01 (DUNS), 12 (phone). | ZZ |
| receiver_qualifier | No | ISA07 qualifier. | ZZ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details beyond the readOnly/idempotent/destructive hints: it computes sequential HL IDs, space-pads every ISA element to a fixed width, and reconciles SE01, CTT01, GE01, and IEA01 counts. Annotations already signal there are no side effects, and the description adds failure-mode context without contradicting them. It does not explicitly state the output format, which keeps this 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?
The description is front-loaded with a one-sentence summary and then justifies the tool by illustrating failure-prone parts of X12. It is somewhat narrative and could be trimmed, but each sentence provides a concrete reason existing, such as 106-character ISA fields and matching segment counts.
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 complex tool with 10 parameters, a deeply nested data parameter, and no output schema, this description covers the most important operational concerns: HL-parent links, fixed-width envelope fields, and count agreement. The only notable gap is not explicitly stating what is returned, though 'compiles into X12' strongly implies a generated document string.
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 all parameters. The prose focuses on why the generated EDI is hard to hand-author rather than adding per-parameter detail. The nested data shape is present in the schema and not expanded in meaningful new ways.
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 opening sentence, "Compiles structured JSON into standards-valid X12," states a specific verb and resource, and the title narrows it to 856 ASN and 850 purchase orders. This clearly differentiates it from siblings like edi_parse and edi_validate. An agent can immediately tell this tool builds EDI rather than parses or validates it.
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 explains when to use it by emphasizing that HL hierarchy bookkeeping, fixed-width ISA fields, and segment counts are exactly the parts that are error-prone when written by hand. It stops short of explicitly naming alternatives or saying 'use edi_validate when you already have an X12 document,' but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a raw ASC X12 interchange and returns it as JSON: delimiters taken from the ISA header, the ISA/GS/ST envelope decoded, every segment split into named elements, and a document-specific summary - purchase order lines for an 850, the HL shipment hierarchy and SSCCs for an 856, invoice totals for an 810. EDI is positional and delimiter-sensitive, and unreadable without a spec table; reading it by inspection produces confident nonsense, which is why this is a tool rather than a prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Raw X12 EDI text, beginning with ISA where available. | |
| include_segments | No | Include the flat segment list alongside the summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnly/idempotent/destructive annotations by explaining what the tool actually does with input: it derives delimiters from the ISA header, decodes the envelope, splits segments into named elements, and returns a document-specific summary. It also cautions about the positional and delimiter-sensitive nature of EDI, which is helpful context for agents.
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 two dense sentences, front-loaded with the actual output and parsing mechanics, and ends with a concise rationale for why the tool should be used instead of direct inspection. The reasoning is a slight digression, but the overall length/material-to-word ratio is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately conveys what the returned JSON includes and even sampling for several document types. It does not elaborate on error scenarios or malformed input behavior, but the core call and derived output are well enough specified for an agent to invoke the tool 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?
All parameters are fully described in the input schema with 100% coverage, so the baseline is 3. The description does not add meaningful parameter-level information beyond the schema, including nothing about the include_segments flag, but it does clarify that the input should begin with ISA when available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reading a raw ASC X12 interchange and returning JSON, with a precise breakdown of the internal processing: delimiter detection, envelope decoding, segment splitting, and document-specific summaries. It includes relevant document types (850, 856, 810, 855, 997), and though it does not mention sibling tools by name, the parse/build/validate distinction is clear from the verb and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is meant for raw X12 text that would otherwise be unreadable by inspection or fact-free prompting, giving a reasonable why and when. It does not explicitly say when to use edi_validate or edi_build instead, and it offers no exclusions or alternatives beyond stating it is a tool rather than a prompt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the structural checks a trading partner runs before rejecting a file: control numbers matching between the ISA/IEA, GS/GE and ST/SE header and trailer pairs, declared counts matching actual counts, and - for an 856 - the HL hierarchy. HL faults are the usual cause of ASN rejections and chargebacks: a parent ID naming no existing node, a duplicate HL01, an unknown level code, a missing carton level. Every finding names the segment and states what the value should have been.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Raw X12 EDI text. | |
| require_levels | No | HL level codes that must be present in an 856, e.g. ["S","O","P","I"] for a pack-level ASN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent hints, the description explains real behavior: it checks ISA/IEA, GS/GE, and ST/SE matching, declared counts, and HL hierarchy, and it details the artifact of output ('Every finding names the segment and states what the value should have been'). There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each containing distinct meaningful content: overall purpose, specific checks (including HL fault types), and output format. It is front-loaded with the primary action and free of redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition provides the input contract (raw X12 + optional required HL levels), the scope of validation, and the nature of findings. Without an output schema, it says what a finding contains but does not describe empty-result behavior or how the whole result is enveloped, leaving a small completeness gap for a validation 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 the description does not need to explain the required 'input' and optional 'require_levels' parameters. It does reinforce the purpose of require_levels for 856 hierarchy checks, but this is more contextual than an addition over the inline parameter said.
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 runs the structural checks that a trading partner runs before rejecting an X12 file, covering envelope control-number matching, declared counts, and 856 HL hierarchy. This clearly distinguishes it from sibling tools like edi_build and edi_parse.
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 contextual guidance: use this when you need to mimic the checks a trading partner carries out before rejection, particularly for ASN/856 documents. It does not explicitly name alternatives or exclusion cases, but the intended trigger is obvious from the phrase 'before rejecting a file.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes cryptographic digests and HMAC signatures. Returns hex and base64 at once, so a webhook signature can be compared in whichever encoding the provider uses. MD5 and CRC32 are included for checksums and legacy fixtures; they are not secure for authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text to hash. | |
| hmac_key | No | When set, computes HMAC-<algorithm> with this key instead of a plain digest. Not supported for md5/crc32. | |
| algorithms | No | Any of: md5, sha1, sha256, sha384, sha512, crc32. | |
| input_encoding | No | How to read `input` into bytes. | utf8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint, idempotentHint, and destructiveHint, so the description adds behavioral value beyond them. It discloses the unusual dual output behavior and the security caveat for MD5/CRC32. There is no contradiction between the description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Each sentence contributes actionable information: what is computed, what the output format enables, and which algorithm choices have security limitations. The most important purpose and output behavior are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent utility, the description combined with the schema covers invocation well: it explains the digest/HMAC behavior, the dual encoding output, and the security-level distinction among algorithms. The only meaningful gap is the exact return JSON shape, especially since there is no output schema, but the described behavior is still enough for an agent to select and call the 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 the baseline is 3, but the description adds a meaningful extra layer for the algorithms parameter: MD5 and CRC32 are for checksums and legacy fixtures and are not secure for authentication. The rest of the parameter semantics are already fully described in the input schema, so the description does not need to restate them.
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: 'Computes cryptographic digests and HMAC signatures,' and the title explicitly lists supported algorithms (MD5, SHA-1, SHA-256/384/512, CRC32). No sibling tool overlaps with hashing, so an agent can distinguish this tool without ambiguity.
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 a concrete use case: comparing webhook signatures in whichever encoding a provider uses, which helps the agent decide when the dual hex/base64 output matters. It also explicitly warns that MD5 and CRC32 are not secure for authentication, steering the agent toward those algorithms only for checksums or legacy fixtures. It does not name alternative hashing tools, but none of the siblings provide hashing, so the guidance is otherwise sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The difference between an agent believing it succeeded and knowing it did. http.check tells you a URL is alive; this tells you it is correct. Assert the status, response headers, values at JSONPath expressions, substrings in the body and a latency ceiling, and get back one boolean plus a per-check breakdown showing expected against actual. An agent that has just deployed, migrated or reconfigured something can prove the outcome rather than reporting the absence of an error, which is the usual way agents claim a success they have not actually achieved.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to call. | |
| body | No | Request body for POST, PUT and PATCH. | |
| method | No | HTTP method. | GET |
| headers | No | Request headers to send. | |
| timeout_ms | No | Request timeout. | |
| expect_json | No | JSONPath expressions mapped to required values, e.g. {"$.status":"ok","$.items[0].id":1}. | |
| expect_status | No | Required status: a number, an array of acceptable numbers, or a class such as "2xx". | |
| expect_headers | No | Response headers that must exist and contain a substring, e.g. {"content-type":"json"}. | |
| max_response_ms | No | Fail if the response takes longer than this. 0 disables the check. | |
| expect_body_contains | No | Substrings that must appear in the body. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real behavioral value beyond the annotations: it discloses the return shape ('one boolean plus a per-check breakdown showing expected against actual') and the philosophical intent ('prove the outcome rather than reporting the absence of an error'). With readOnlyHint, idempotentHint, and destructiveHint already covering safety, the description does not need to restate those properties, and it avoids doing so.
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 paragraph is a bit longer than strictly needed, but every sentence earns its place: a memorable differentiator, a compact list of assertion capabilities, and the return behavior. It is front-loaded with the core idea and does not repeat the input schema verbatim, though it could trim a few rhetorical words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, the description conveys the main context an agent needs: when to use it, what it asserts, and what output to expect. A small gap remains — it does not define what 'pass' means if no assertions are configured — but the schema and examples cover the rest well.
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%; every parameter already carries types, defaults, bounds, or examples. The description summarizes the assertion axes without introducing any new parameter semantics, so it meets the high-coverage baseline of 3 rather than rising above it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title is a clear verb+resource statement: 'Verify a URL actually returns what you expected — status, headers, JSON values — and return a pass/fail proof.' The description also names exactly what it checks (status, headers, JSONPath values, body substrings, latency) and explicitly distinguishes itself from the sibling http_check, so an agent knows what it does and what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'http.check tells you a URL is alive; this tells you it is correct,' an unambiguous alternative-vs-this distinction. It also gives a concrete scenario, 'an agent that has just deployed, migrated or reconfigured something,' making the when-to-use condition clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves a URL and reports what actually happens to it — final status, the full redirect chain, content type and page title. Link rot is faster than it feels: one agent measured seven dead URLs out of 286 across fourteen days. This handles the three cases a naive checker gets wrong: an arXiv v1 to v2 redirect is a version change, not a break; a 403 is a blocked crawler, not a dead page; and a DOI can return 200 while the page behind it is now a retraction notice, which is the worst case because a simple status check passes and the reader gets something else. Response bodies are never returned — only status, headers, title and flags.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check. | |
| timeout_ms | No | Per-request timeout in milliseconds. | |
| max_redirects | No | How many redirects to follow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses key behavioral traits: it follows redirects, reports the chain, never returns response bodies, treats 403 as a crawler block rather than death, and flags retraction-style false 200s. This materially helps an agent trust and interpret results.
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 core behavior is front-loaded in the first sentence, and the edge-case examples are operationally relevant. The link-rot anecdote is mildly tangential but strengthens the rationale without bloating the entry. Overall it is efficient for the information being conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains what will be returned: status, redirect chain, content type, page title, and flags. It also covers safety constraints, edge cases, and common misleading status codes, providing a complete mental model for correct invocation.
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 fully documents url, timeout_ms, and max_redirects. The tool description does not add parameter-specific meaning beyond illustrating URL use with an arXiv example. A baseline of 3 is appropriate because the schema carries the load.
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: 'Resolves a URL and reports what actually happens to it' with final status, redirect chain, content type, and page title. The title adds the citation-integrity purpose, and the edge cases clearly distinguish it from a naive HTTP status checker. Purpose is fully clear.
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 strong situational context for when to use this tool, especially for detecting link rot and cases where a simple status check is misleading. It does not explicitly name alternatives or state when not to use it, but the sibling list shows unrelated tools, so no exclusion is strictly needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a JSONPath query and returns the matching values with their concrete paths. Supports property access, array indexing (including negative indices), slices, wildcards, recursive descent (..) and filters ([?(@.price > 10)]). Pull three fields out of a large API response without carrying the whole document through context.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | The JSON document, as an object or a JSON string. | |
| path | Yes | JSONPath expression, e.g. "$.items[*].id" or "$..author". | |
| first_only | No | Return only the first match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description only needs to add meaningful behavior details. It does so by noting that results include concrete paths and by supporting broad JSONPath syntax such as recursive descent and filters. There is no contradiction with the annotations, and this complements the schema without restating it.
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 compact and front-loaded, leading with what the tool does and what it returns. The second kernel sentence enumerates supported JSONPath syntax, and the final sentence gives a useful practical use case without unnecessary 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 all parameters covered by the schema and the description providing the return shape, this is sufficiently complete for everyday use. It could mention behavior on invalid JSONPath expressions or empty results, but those are edge cases on a pure, idempotent query tool and do not seriously impede correct invocation.
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; the description improves on this by documenting the JSONPath capabilities: property access, array indexing, negative indices, slices, wildcards, recursive descent, and filters. This adds real semantic context to the path parameter beyond the generic examples in the schema. It does not need additional parameter documentation.
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 action and resource: 'Runs a JSONPath query' against a JSON document and returns results. It clearly differentiates this from sibling json_repair, since this is a read-only extraction tool rather than a corrective one. The output shape, 'matching values with their concrete paths', also clarifies its role.
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 a concrete use case: 'Pull three fields out of a large API response without carrying the whole document through context.' This implies when to use the tool, and the JSONPath feature list further clarifies the kind of queries it supports. It does not explicitly name or exclude alternatives, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes JSON that almost parses and makes it parse: markdown code fences, prose wrapped around the object, trailing commas, single or smart quotes, unquoted keys, Python True/False/None, comments, NaN, and brackets left open by a truncated response. Every change is reported, so the caller learns what its generator got wrong rather than silently depending on a fixer. When the input cannot be salvaged it returns the precise line, column and a caret pointing at the offending character — which is what makes the next attempt succeed instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The malformed JSON text. | |
| close_truncated | No | Close brackets left open by a cut-off response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool read-only and idempotent; the description then adds meaningful behavioral detail: every repair is reported rather than silently applied, and unrecoverable inputs return line, column, and caret. This is exactly the transparency an agent needs before relying on a fixer.
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 core purpose and stays compact. Every sentence carries value, from supported malformed forms to the non-silent repair guarantee to the failure diagnostic.
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 helper with full schema coverage and read-only/idempotent annotations, this description is highly actionable. It explains what inputs it repairs, what happens on failure, and that changes are visible to the caller. The only soft spot is that, with no output schema, the successful return shape is described behaviorally rather than structurally.
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?
Both parameters have schema descriptions, so the baseline is covered. The description adds extra meaning by illustrating realistic malformed-JSON inputs for the input string and by connecting close_truncated to truncated responses with unclosed brackets.
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 uses a specific verb-resource pairing — "Takes JSON that almost parses and makes it parse" — and backs it with a concrete list of malformed forms. This clearly distinguishes it from siblings like json_query or edi_parse.
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 precise usage context: call this when JSON has markdown fences, prose wrapping, trailing commas, quote variants, unquoted keys, Python literals, comments, NaN, or truncation. It does not explicitly name alternatives, but the boundary against query/parse siblings is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates arithmetic with correct operator precedence, parentheses, exponentiation, factorials, named variables and 30+ functions. Language models perform arithmetic by pattern-matching and quietly get long multiplications and compounding wrong; this computes the number instead of predicting it.
| Name | Required | Description | Default |
|---|---|---|---|
| precision | No | Decimal places to round the formatted result to. | |
| variables | No | Named values usable in the expression, e.g. {"rate": 0.07}. | |
| expression | Yes | Expression to evaluate, e.g. "(1+0.07)^30 * 1000". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a read-only, idempotent, non-destructive operation. The description adds useful behavioral context: it guarantees correct operator precedence and warns that language models commonly get long multiplications and compounding wrong. This gives the agent a trustworthy reason to delegate arithmetic 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?
Two compact, information-dense sentences. The first defines capability, the second conveys rationale and reliability. There is no redundant repetition of schema fields or annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and annotations cover inputs and safety, and the description gives the purpose and interpretability rule. There is no output schema, and the description does not explicitly mention the response format or error behavior, but for a simple exact-evaluation tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters 100% with clear descriptions. The tool description reinforces but does not extend parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a strong verb ('Evaluates') and clearly specifies the resource/behavior: arithmetic with precedence, parentheses, exponentiation, factorials, variables, and 30+ functions. It also distinguishes the tool's value from the language model's fallible pattern-matching arithmetic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a reliable computed arithmetic result is needed instead of the language model's potentially wrong estimate. It doesn't name explicit when-not-to-use conditions or alternative sibling tools, but the context is clear enough given no arithmetic siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts one instant into any number of timezones, handling daylight saving transitions correctly. Naive inputs (no Z or offset) are read as wall-clock time in from; inputs carrying an offset are absolute.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target timezones. | |
| from | No | Timezone the input is expressed in (used only when it carries no offset). | UTC |
| time | No | The instant to convert: ISO 8601, a naive wall-clock time, a unix timestamp, or "now". | now |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description additionally clarifies an important behavioral nuance: naive inputs are interpreted in `from` while inputs with offsets are treated as absolute. This exceeds what the annotations alone provide, though output format is not described.
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?
Two sentences, each earning its place. The first states the core operation and important DST behavior; the second disambiguates input interpretations. No filler or redundant detail.
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 read-only conversion tool with one required parameter and fully documented parameters, the essential invocation semantics are present. The lack of an output schema means the return format is not explicitly defined, but it is reasonably inferred from 'converts into any number of timezones'.
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 input schema already documents `to`, `from`, and `time`. The description adds brief clarity about naive vs offset inputs, but it mostly restates semantics already provided in the parameter descriptions.
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: 'Converts one instant into any number of timezones.' The behavior is unambiguous and easily distinguished from sibling tools like time_now, time_diff, and time_window.
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 clearly establishes when this tool fits: timestamp conversion across timezones with DST awareness. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over the other time-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the elapsed time between two instants: exact totals in each unit, a calendar breakdown (years/months/days rather than 'thirteen and a half months'), the count of weekdays in between, and a human phrase. Negative when to precedes from.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End instant: ISO 8601, unix timestamp, or "now". | now |
| from | No | Start instant: ISO 8601, unix timestamp, or "now". | now |
| timezone | No | IANA timezone identifier, e.g. "UTC", "America/New_York", "Asia/Kolkata", "Europe/London". | UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds substantial value by disclosing the output categories, the calendar-based breakdown convention, the inclusion of weekday count, the human phrase, and the negative-sign behavior when `to` precedes `from`. This is exactly the kind of behavioral detail 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?
Two sentences carry all essential information with no filler. The description front-loads the main action, then efficiently enumerates output categories and the one important edge case about negative results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero required parameters, no nested objects, a complete schema, and a pure read-only behavior. The description fully conveys what the tool returns, how results are formatted conceptually, and how direction affects the output, which is sufficient even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline applies. The description adds only a small useful behavioral cue around argument order ('Negative when `to` precedes `from`'), but it does not add substantially new meaning to the three parameters beyond what the schema already documents.
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 uses a specific verb and resource ('Computes the elapsed time between two instants') and then enumerates exactly what the tool returns: totals in each unit, calendar breakdown, weekday count, and a human phrase. This is specific enough to distinguish it from sibling time tools like time_now, time_convert, and time_window without needing to open schemas.
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 clearly implies when to use the tool: whenever an agent needs elapsed time or duration between two instants. It does not explicitly name alternatives or exclusion conditions, so it stops short of full routing guidance, but the context is clear and there is no ambiguity about its core use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the authoritative current time in one or more timezones, with UTC offset, ISO week number, day of year, weekend flag, and daylight-saving state. Use this instead of guessing the date: a language model has no clock, and its training cutoff is not today.
| Name | Required | Description | Default |
|---|---|---|---|
| also | No | Additional timezones to report alongside the primary one. | |
| timezone | No | IANA timezone identifier, e.g. "UTC", "America/New_York", "Asia/Kolkata", "Europe/London". | UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations readOnlyHint, idempotentHint, and destructiveHint already present, the description adds meaningful behavioral context: reports UTC offset, ISO week, day of year, weekend flag, and DST state, and asserts the value is authoritative. That goes beyond the annotation and outlines observable output.
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?
Two sentences, front-loaded with the core purpose and output contents, followed by a motivation for using the tool. It is concise and avoids filler, with every sentence contributing to operational clarity.
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?
Even though there is no output schema, the description enumerates the main return fields: UTC offset, ISO week number, day of year, weekend flag, and daylight-saving state. Combined with a clear usage rationale and optional `also` parameter, it provides enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the description is not required to re-document parameters. It adds minimal direct parameter detail, but the 'one or more timezones' phrase helps map the primary timezone and the `also` array. This meets the baseline threshold without going beyond.
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 is crisp and specific: 'Returns the authoritative current time in one or more timezones' with a clear resource (time) and an explicit scope. It distinguishes itself from sibling tools like time_convert or time_diff by centering on the current clock and a IANA timezone.
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 guidance: 'Use this instead of guessing the date: a language model has no clock, and its training cutoff is not today.' This gives a strong contextual cue for when, and why, to call it. It does not explicitly mention alternatives/exclusions like time_convert, so it stays at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers the questions a deadline actually poses: is this instant inside the window, how long until it opens or closes, and if it is outside, by how much. Optionally compares two windows for overlap. A window comparison that silently succeeds against the wrong bounds is a failure mode that does not raise an error anywhere — the ship window is missed, or the ASN is late, and the only symptom is a chargeback later. This computes the boundary instead of assuming it.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window closes at this instant. Omit if using `duration_hours`. | |
| start | Yes | Window opens at this instant: ISO 8601, unix timestamp, or "now". | |
| instant | No | The instant to test against the window. | now |
| timezone | No | IANA timezone used to read naive inputs and render output. | UTC |
| compare_end | No | End of the second window. | |
| compare_start | No | Start of a second window, to test for overlap with the first. | |
| duration_hours | No | Window length in hours, used when `end` is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent, and non-destructive. The description adds meaningful context beyond that: it warns about silent boundary failures and claims the tool computes boundaries rather than assuming them. It does not describe the exact output structure, so some behavioral detail remains uncovered.
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 most important information is front-loaded: core questions, optional comparison, and a warning about silent failure. It is not bloated, though the 'ship window / ASN / chargeback' framing is somewhat illustrative and could be trimmed without losing meaning.
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 7-parameter tool with no output schema, the description covers the key behaviors and the kind of results returned: inside/outside status, time to open/close, miss amount, and overlap. It leaves some specifics—such as exact return field names and timezone effects—to the schema, but overall this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself already documents all seven parameters. The description provides overall conceptual context but does not add field-level detail or nuance about how parameters work beyond what the input schema already gives.
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 clear and specific purpose: test whether an instant falls inside a time window, quantify how far outside it is, how long until it opens/closes, and optionally compare overlaps. This distinguishes it from the sibling time tools, especially time_diff, time_convert, and time_now.
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 usage context around deadline handling and window overlap checking, using concrete examples like missed ship windows and late ASNs. It does not explicitly name sibling alternatives or state when-not-to-use, 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.
Dispatches to any tool in the catalogue. Most clients cap how many tools they will hold at once — Cursor drops everything past roughly forty across all servers combined — so only a core set is listed by default. Everything else is reachable here. Find a name with tool.search, check its shape with tool.describe, then call it through this.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for that tool. | |
| tool | Yes | Name of the tool to invoke. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There is an annotation contradiction. The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, while the description says the tool can call anything in the catalogue, including other tools whose effects may be mutating and non-idempotent. The description does not warn that target tool side effects, permissions, or errors will apply, which is a significant disclosure gap.
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 compact and front-loaded: the first sentence states purpose, the second explains why default listings are incomplete, and the third gives a concise discovery and invocation workflow. Every sentence adds useful selection information, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic arbitrary-dispatch tool, this is incomplete: it should warn that invoking other tools may trigger their own side effects, permission requirements, and outputs. The read-only/idempotent annotation makes that gap worse. The workflow it gives is helpful, but it does not prepare the agent for the broad behavior of the tools it may invoke.
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 schema has 100% description coverage for both parameters, so the description has little additional burden. It does add the workflow that a name should be found with tool_search and its shape checked with tool_describe, but this is context rather than new parameter semantics. The default meaning of 'args' is left to the schema, which is adequate.
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: 'Dispatches to any tool in the catalogue.' It also clarifies scope by noting it can reach tools omitted from the default listing, and it names complementary siblings tool_search and tool_describe. An agent can distinguish this invocation tool from the search/inspection tools without reading their schemas.
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 guidance: use this when a tool is not listed by default, and route through tool_search and tool_describe first. The explicit workflow is useful. It stops short of saying 'call listed tools directly instead of using this,' but 'everything else is reachable here' makes the intended selection clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns everything needed to call a tool correctly: its complete JSON Schema, every parameter with type and default, and examples known to work. Pair it with tool.search — search to find the name, describe to learn the shape, then call. This exists so the catalogue does not have to be loaded into context up front.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Tool name, e.g. "time.window". Underscores and slashes are accepted too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the read-only, non-destructive, idempotent contract, and the description adds meaningful behavioral detail: what it returns, that the output includes schema/examples, and that it is a lightweight catalog-access strategy. It does duplicate the title somewhat, but describes behavior beyond what annotations state.
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 focused sentences: the first states the core output, the second gives the exact workflow, and the third explains the context-level rationale. Every sentence earns its place, and the key content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description fully closes the gap: it explains what the return payload contains, how this fits into the search/describe/call sequence, and it relies on annotations for safety. Nothing essential 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 schema already documents the 'name' parameter, its example, maxLength, and accepted separators. The description does not need to compensate for schema gaps; it stays at the baseline by not adding further parameter-level guidance.
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 action ('Returns everything needed to call a tool correctly') and a specific resource ('one tool'), naming the exact deliverable: complete JSON Schema, parameter types/defaults, and worked examples. It also distinguishes itself from tool_search by explaining that search finds names while describe learns the 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 an explicit workflow: pair it with tool.search — search, describe, then call. It also explains the underlying purpose: 'This exists so the catalogue does not have to be loaded into context up front,' which tells the agent when this tool is the efficient choice versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches every tool by name, summary, description and keywords, and returns the closest matches with their endpoints and parameters. Use this instead of loading the whole catalogue: describe the job ("check whether a shipment is late", "fix broken JSON", "validate a barcode check digit") and call what comes back. Each result says why it matched, so a wrong match is obvious rather than plausible.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | What you are trying to do, in plain language. | |
| limit | No | Maximum matches to return. | |
| detail | No | Include full parameter schemas and worked examples for each match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark this as read-only and non-destructive, the description adds meaningful behavioral detail beyond annotations: it searches across multiple fields, returns ranked closest matches, and each result includes an explanation of why it matched. This helps the agent identify false positives and trust the result mapping.
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 compact but dense with useful content: what is searched, what is returned, when to use it, and how to judge the quality of results. Every clause earns its place, and there is no boilerplate or restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a search-related tool with three straightforward parameters. It tells the agent what gets searched, why it will accept plain-language input, what the output contains, and how to verify the output is relevant. Since there is no output schema, the description's return-shape guidance is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all three parameters already have clear schemas: q, limit, and detail. The description adds helpful plain-language examples for q, but it does not substantively add meaning beyond what the schema already communicates. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that this tool searches all tools by name, summary, description, and keywords, and returns closest matches with endpoints and parameters. This is a specific verb-resource-action statement that clearly differentiates it from sibling tools like tool_describe or tool_call.
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 explicit guidance: use this instead of loading the whole catalogue when you can describe a task in plain language. It provides concrete examples of natural-language queries and even tells the agent to call what comes back, making the decision to use this tool versus more exhaustive lookup approaches obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
doc_extractdomain_lookuphttp_assertcron_nextedi_buildedi_parseedi_validatehashhttp_checkjson_queryjson_repairmath_evaltime_converttime_difftime_nowtime_windowtool_calltool_describetool_searchClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
44 tools for AI agents: Trends, SERP, SEO audits, screenshots, weather, FX, whois, RSS.
40+ Lightning-paid AI tools for agents: calls, SMS, fax, voice, translation. No signup, no keys.
29 pay-per-call DNS, SEO, SSL, security, and dev tools for AI agents. x402, no API key.
13 micro-tools for agents: read pages, verify email, convert, validate, diff, extract. AI-operated.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct purpose: EDI build/parse/validate, JSON query/repair, time now/convert/diff/window, and tool search/describe/call are all cleanly separated. Even the time-related tools address non-overlapping questions.
Most tools follow recognizable group patterns: edi_*, time_*, json_*, tool_*. A few exceptions like hash, cron_next, and math_eval break the verb_noun pattern, but the naming remains readable and predictable overall.
Sixteen tools is slightly above the ideal 3-15 range, but the server covers several utility domains and each tool has a concrete, non-redundant purpose. It feels broad but not bloated, and the meta tools help offset the count by keeping the full catalogue discoverable.
The set covers its apparent domains well: EDI has build/parse/validate, time has current/convert/diff/window/cron, JSON has query/repair, and the tool catalogue has search/describe/call. Minor gaps exist, such as no generic HTTP request tool or broader JSON transformation, but these appear deliberate rather than accidental.
