X12 EDI, GS1 check digits, time, cron, JSON repair, crypto for AI agents. Free, no key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 16 of 16 tools scored. Lowest: 3.4/5.
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.
cron_nextValidate a cron expression, explain it in English, and list its next run times.AParses 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.
edi_buildGenerate a valid X12 856 ASN or 850 purchase order from JSON, with correct HL pointers and envelope counts.ACompiles 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.
edi_parseParse an X12 EDI document (850, 856, 810, 855, 997 and others) into structured JSON.AReads 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.
edi_validateCheck an X12 document's envelope integrity and 856 HL hierarchy for the errors that cause rejections.ARuns 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.
hashHash or HMAC-sign text with MD5, SHA-1, SHA-256/384/512 or CRC32.AComputes 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.
http_checkCheck whether a URL is still live: status, redirect chain, and whether a citation still says what it said.AResolves 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.
json_queryExtract values from a JSON document with a JSONPath expression.ARuns 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.
json_repairRepair malformed JSON and pinpoint the exact line and column when it cannot be repaired.ATakes 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.
math_evalEvaluate a mathematical expression exactly.AEvaluates 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.
time_convertConvert a timestamp between timezones.AConverts 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.
time_diffDuration between two dates, in every unit.AComputes 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.
time_nowCurrent date and time in any IANA timezone.AReturns 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.
time_windowTest whether an instant falls inside a time window, and by how much it misses.AAnswers 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.
tool_callInvoke any tool by name, including ones not in the default listing.BDispatches 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.
tool_describeGet the full parameter schema and worked examples for one tool.AReturns 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.
tool_searchFind the right tool for a task by describing it in plain language.ASearches 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!