AgisHub MCP Server

Official

by agishub

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation4/5
Most tools are clearly distinct in purpose, but there are several timezone-related tools (now_in, convert_timezone, convert_batch, tz_offset, list_timezones, lookup_timezone) that could be confusing at first glance. The descriptions help, but the overlap in that domain is noticeable. 'extract' and 'extract_entities' are also somewhat close in name but serve different functions.
Naming Consistency3/5
All names use snake_case, which is good, but there is inconsistency between verb_noun forms (convert_timezone, list_timezones), single-verb forms (extract, summarize, classify), and noun forms (price, status, qr_code). Some prefixes are repeated (convert_*, memory_*), but overall the pattern is not uniform across the set.
Tool Count3/5
With 25 tools, this server is at the upper bound of what feels reasonable. Each tool seems individually useful, but the set is very broad, spanning timezones, text processing, webhooks, URL utilities, crypto, and more. It feels heavy rather than well-scoped, but not excessively so.
Completeness3/5
Because the server covers many unrelated domains, it's hard to assess completeness. Within each domain, there are gaps (e.g., memory lacks delete/collection management, webhooks lack cancellation). However, for general-purpose utilities, it offers a wide range of functionality, so the overall surface is not severely incomplete.
Average 4/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool reports one of four statuses, which gives insight into possible outcomes. However, it does not mention authentication requirements, error behavior for unknown job_ids, or whether the operation is strictly read-only (though 'check' implies it). The description adds some behavioral context but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, lists the relevant statuses, and names the key parameter. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with one parameter and no output schema, the description is fairly complete: it tells you what the tool does, what statuses to expect, and what input is needed. However, it does not describe the output format (e.g., whether it returns just a status string or additional metadata), nor does it address error cases like an invalid job_id. Given its simplicity, this is a minor gap, so 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter job_id, with a clear description that it is returned by webhook_relay. The description's mention of 'by its job_id' adds no additional semantic value beyond what the schema already states. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (check) and the resource (delivery status of a webhook job), and even enumerates the possible statuses (queued/retrying/delivered/failed). It is specific and unambiguous, but it does not explicitly distinguish from sibling tools such as 'relay', which might be seen as the complement. Thus it meets the bar for clear purpose without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: when you have a job_id from webhook_relay and want to know its delivery status. The parameter schema reinforces this by specifying that job_id is returned by webhook_relay. However, there is no explicit guidance on when to use this tool vs alternatives, nor any stated prerequisites or exclusions, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only mentions file format support and does not describe output format, potential latency, size limits, or permissions. This is a significant gap for a tool that performs an asynchronous-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and supported formats without redundancy. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides the essential input requirement (public URL) and output type (text). However, it lacks details about the response format or any restrictions, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the parameter with a description matching the tool's own text. The description adds nothing beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Transcribe') and resource ('audio file'), and notes supported formats. It's easily distinguishable from the unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (transcribing audio to text) but doesn't explicitly state when to prefer this tool over alternatives or provide exclusion criteria. Since no sibling tool performs transcription, it's clear by context, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a useful behavioral fact ('No external API key required'), but does not disclose other traits like data handling, rate limits, or output format. It does not contradict anything, but coverage is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary purpose and a key operational fact (no API key). Every word earns its place; it is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple chat tool, the description covers the core purpose but omits expected return behavior, error conditions, or any limitations. With no annotations or output schema, a bit more context would be valuable, but the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds no extra semantic value beyond reaffirming the optional system prompt, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Ask') and resource ('general-purpose LLM'). It distinguishes itself from specialized sibling tools via the 'general-purpose' qualifier, and mentions the optional system prompt, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'general-purpose', suggesting use when specialized tools (e.g., summarize, classify) are not appropriate. However, no explicit when-to-use or when-not-to-use guidance is given, nor are alternative tools named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden. It discloses that rates are daily and live, and that the return includes the converted amount and rate. However, it omits details about error handling, precision, or any caveats about the rate source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose, and includes return behavior without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with full schema coverage and no output schema, the description adequately covers purpose, inputs, and return value. It lacks edge-case details but is sufficient given the tool's simplicity and low risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters; the description adds ISO 4217 code examples but these are already implied by the schema's own text. It does not materially extend schema semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert an amount between currencies' with a specific verb and resource, and distinguishes from sibling tools like convert_timezone and convert_units by explicitly referencing currencies and ISO 4217 codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (currency conversion with live daily rates) but does not explicitly mention alternatives like convert_batch or provide exclusions. Usage is implied but no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns structured JSON, which is a useful behavioral detail, but it does not mention side effects, permissions, language limitations, or any edge cases. For a read-only extraction tool this is adequate but minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that covers the action, the input type, the entity categories, and the output format. Every phrase carries meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description gives enough context: it explains the input, the types of entities recognized, and that the result is JSON. It could be more specific about the exact JSON shape or additional options, but it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, 'text', is described in the schema already. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Extract' and clearly identifies the resource as 'named entities from text', listing the categories (people, organizations, locations, dates, miscellaneous) and stating the output format. This distinguishes it well from the sibling 'extract' tool, making its specialized function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does, but it does not explicitly state when to prefer this tool over alternatives like 'extract', nor does it mention any exclusions or prerequisites. The context is clear enough for straightforward entity extraction, but there is no guidance on alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that no external API key is required, which is useful, but it does not explicitly state that the operation is non-destructive, mention any rate limits, or describe how the input is processed. The description is quite minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main purpose, followed by the optional parameter and a key behavioral note. Every word adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description is mostly complete. It covers the main function, optional length, and the no-API-key aspect. However, it does not explicitly state the return format (e.g., a string summary), which is a minor gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds the phrase 'optional target length' which maps to max_words, but it does not provide significant additional meaning beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Summarize a block of text into a short abstract' with a specific verb and resource. It distinguishes from sibling tools by focusing on summarization rather than extraction, classification, or transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a summary of text is needed, but it does not explicitly compare to alternatives or state when not to use it. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. It mentions read-only operations ('list or search') and filtering, but does not detail output format, potential limits, or other behavioral traits. This is acceptable for a simple list tool but leaves room for more transparency, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each adding value: the first explains the core action and filter, the second clarifies the purpose. There is no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential context: what it does, what the filter does, and why to use it (to get identifiers for other tools). It could optionally mention the return format, but it is sufficiently complete for the tool's simplicity, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'query' parameter as a case-insensitive substring filter, but the tool description adds concrete meaning by specifying it can be a city, region, or country and providing examples ('kolkata', 'america'). This enriches parameter understanding beyond the schema, so it earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to list or search valid IANA timezone identifiers. It uses a specific verb ('list or search') and identifies the resource, but it does not explicitly contrast with sibling tools like lookup_timezone, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this tool to discover the exact identifier to pass to other tools. It implies when to use it but does not list exclusions or alternative tools explicitly, which keeps it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that prices are live and in USD, and 'get' implies a read-only operation. However, it does not disclose potential latency, error behavior for invalid symbols, or any limits on batch size. For a simple lookup tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get live USD spot prices for one or more cryptocurrencies by ticker symbol (e.g. BTC, ETH, SOL).' It is efficient, contains no filler, and includes examples to aid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema, the description is mostly sufficient. It states the purpose and examples, but does not specify the response format (e.g., a map of symbols to prices). Without an output schema, this is a minor gap, but not severe for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter 'symbols' is fully described with format and return currency. The description repeats the example tickers but adds no new meaning beyond the schema. Thus the baseline score of 3 is appropriate; the schema already carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting live USD spot prices for cryptocurrencies by ticker. The verb 'get' and resource 'cryptocurrency prices' are specific, and the examples (BTC, ETH, SOL) help clarify. It distinguishes itself from siblings like convert_currency by focusing on crypto spot prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need live USD spot prices for cryptocurrencies. The cryptocurrency scope implicitly excludes fiat currencies and other tools like convert_currency. However, it does not explicitly mention alternatives or state 'do not use for fiat', so it falls short of a fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: the text is classified into exactly one of the provided labels, which is beyond what the schema states. With no annotations available, it carries the full disclosure burden, but it does not cover edge cases like ambiguous texts or the exact return format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'Classify' and provides a compact example. There is no fluff or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool without output schema or annotations, the description is largely sufficient. It explains the task, the 'exactly one' constraint, and the user-supplied labels. It could be improved by explicitly stating the return value (e.g., the chosen label), but the behavior is reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter description coverage, with clear definitions for 'text' and 'labels'. The description adds no new parameter-level information beyond reinforcing that labels are user-supplied, so the baseline of 3 (with full schema coverage) applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Classify') with a clear object ('a text') and defines the scope ('exactly one of the candidate labels you provide') with examples (sentiment, topic, intent). This clearly distinguishes it from sibling tools like summarize or extract_entities, which perform different NLP tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: when you need to assign a text to one of a set of user-defined categories. However, it does not explicitly mention when not to use it or point to any alternative tools, lacking exclusions that would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return payload (converted datetime with UTC offset, zone abbreviation, DST flag) and accepted input formats (ISO 8601 or natural language), which is useful behavioral context. However, it does not mention error behavior or edge cases like invalid timezones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first stating the core action and the second covering input formats and return value. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and no output schema, the description sufficiently explains the return format and supported inputs. It doesn't cover batch usage or edge cases, but it is complete enough for a straightforward conversion tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (datetime, from, to) already described. The tool description adds no new parameter-level semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Convert') and resource ('a specific date/time from one IANA timezone to another'), clearly distinguishing it from likely batch siblings like convert_batch. It is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a specific' implies singular conversion, giving some context, but no explicit guidance on when to use this tool versus alternatives like convert_batch or tz_offset is provided. Usage is implied, not clearly stated with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that conversions are restricted to same-category units and specifically mentions the three temperature scales, but it does not explain error handling for incompatible units, rounding/precision behavior, or whether unit matching is case-sensitive. This adds some behavioral context beyond the basic purpose, but not enough for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the action and scope. Every word adds value, listing categories without superfluous detail. It is perfectly concise for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, complete parameter schema, and absence of an output schema, the description is quite complete. It covers the core usage and scope, though it does not explicitly describe the return format (e.g., numeric result) or behavior on invalid input. Still, for a unit converter, this is largely inferable, and the category list provides useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides thorough descriptions for all three parameters (100% coverage), so the baseline is 3. The description's category list reiterates what the schema's examples imply but doesn't add new parameter-level detail. It does reinforce the 'same category' constraint, but this is already in the schema's 'to' field description, so no significant extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Convert a value between units') and a well-defined resource (units of the same category) while listing eight concrete measurement categories. This distinguishes it from sibling tools like convert_currency and convert_timezone by explicitly limiting scope to physical/digital units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context by listing categories and requiring 'same category', which tells the agent when to use this tool. It doesn't explicitly name alternatives (e.g., 'for currency, use convert_currency'), but the category list effectively excludes them, giving clear guidance without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that the tool returns the holiday name if the date is a holiday and mentions an authoritative public-holiday dataset, which adds helpful context. However, it does not disclose the exact return format for non-holiday dates, invalid country codes, or edge cases, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, immediately states the core purpose, and avoids unnecessary detail. It is well-structured and front-loaded with the action and expected result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two clearly described parameters, and the description covers the main purpose and conditional output. However, because there is no output schema, it would be more complete to explicitly state what happens when the date is not a holiday or when the country code is invalid, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters with 100% coverage. The description echoes the ISO 3166-1 alpha-2 code requirement but does not add significant semantic detail beyond what the schema already specifies, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether a given date is a public holiday in a specified country and returns the holiday name if applicable. It is specific about the input (date and ISO country code) and the output behavior, making it easily distinguishable from the sibling tools, which are mostly time/date conversion or generic utilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to check if a date is a public holiday in a country. It does not explicitly mention when not to use it or alternative tools, but the intended use case is obvious and no sibling tool directly competes with this functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose key behaviors: persistence, searchability, embedding, and indexing. However, it does not mention that 'upsert' can overwrite an existing entry when an id is provided, which is a meaningful behavioral aspect not covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core action and key processing details without any fluff. It is efficient, front-loaded with the verb, and perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers persistence and semantic recall for a 3-parameter tool with no output schema. It lacks explicit return-value information and does not mention the update capability, but those are partially addressed by the id parameter description, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds context for 'namespace' as a collection key and 'text' as content, but no additional parameter-level detail beyond that, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores text into a persistent, searchable memory namespace, and it mentions embedding/indexing for semantic recall. This is a specific verb+resource and unmistakably distinguishes a write operation from sibling tools like memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving text for later retrieval but gives no explicit guidance on when to prefer this tool over alternatives like memory_search. There is no mention of when not to use it or any prerequisites, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses DST awareness and fractional offset handling, which is valuable. However, it does not mention behavior for invalid timezones, return format, or how 'instant' is parsed, leaving some gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and the second sentence adds meaningful edge-case information without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description is sufficient for selection. It covers the main behavior and edge cases. A minor gap is not describing the return format, but that is not critical for a read-only offset lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds context about 'at a given instant' but does not provide additional detail beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting the exact UTC offset of an IANA timezone at a specific instant. It distinguishes itself from sibling tools like convert_timezone by focusing on offset retrieval rather than conversion, and highlights special handling of DST and fractional offsets, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need a DST-aware offset for a given instant, and it hints at edge cases like India and Nepal. However, it does not explicitly mention when not to use it or recommend alternatives, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core batch behavior ('many IANA timezones at once') and the world-clock view, but does not detail edge cases like invalid timezone handling, output format, or whether results are keyed by timezone. This is moderate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each earning its place: the first defines functionality, the second clarifies the relationship to the sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the main use case well, including a helpful analogy ('world-clock view'). However, without an output schema or annotations, the agent must infer the return format and error behavior for a batch operation, leaving a small but noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage). The description adds only the batch nuance that 'to' is a list of zones, which is also in the schema. Since schema does the heavy lifting, this is a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a single instant into many IANA timezones at once, and explicitly contrasts it with convert_timezone by noting the 'to' field is a list. This distinguishes it from siblings and gives a specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the sibling convert_timezone as the alternative and explains the exact difference ('to' is a list), providing clear guidance on when to use this batch variant vs the single-zone version. No exclusions are needed for a tool with such a focused purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that pages may come back empty without rendering ('would otherwise come back empty'), and explains that render executes JavaScript first. It also notes the output is 'token-efficient Markdown' which implies content cleaning. It does not detail authentication failures, rate limits, or error behavior, but the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and wastes no words. It includes a clear statement of output format, a crucial usage hint, and a target use case. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description gives a solid overview of inputs (via schema) and outputs (Markdown with listed components). It mentions the render edge case that could affect expected results. It does not explain truncation behavior, but that is covered in the schema. Overall, it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions. The tool description adds minimal extra meaning beyond the schema—it restates the render behavior but does not clarify other parameters like max_chars or include_links beyond what the schema already says. Thus the description does not need to compensate, and the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch any public web page and return its main content as clean, token-efficient Markdown'. It uses specific verbs ('Fetch', 'return') and a resource ('web page'), and explicitly lists what the output includes (title, description, headings, links, lists). This eliminates ambiguity and distinguishes it from the sibling tool 'extract_entities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Built for RAG and for agents that need to read the contents of a URL.' It also gives specific guidance on when to set 'render:true' for JavaScript-heavy pages. However, it does not explicitly mention when not to use the tool or alternatives, so it stops short of a full 'when not' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the free-tier slot limit, the paid endpoint behavior, weekend/holiday exclusion, and hints at the 'upgrade' field in the response. This provides valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence packs the core functionality, and the second adds tier-specific behavior. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key logic (overlap, working hours, weekends, holidays) and the free/paid tier distinction. It does not specify the exact response structure beyond mentioning 'upgrade', but given the lack of an output schema, it provides a reasonable overview 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 3 parameters with 100% coverage. The description does not add significant new meaning to the parameters, only reiterates the country-based holiday exclusion, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' with a clear resource 'working-hour time slots that overlap across participants in different timezones'. It explicitly states the purpose and differentiates from sibling tools like convert_timezone by focusing on overlap calculation rather than single-time conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description presents a clear scenario for use: scheduling a meeting across participants in different timezones. However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of providing full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only lookup but does not disclose behavior for ambiguous names, multiple matching timezones, or error handling. It does provide an example and notes that results are IANA timezone(s), adding some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and example, and has no filler. Every sentence adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (1 param, no output schema), the description is mostly complete: it states purpose, usage context, and example. However, it does not specify whether output is a string or array when multiple timezones match, nor how failures are handled, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single parameter 'city_or_country' with a clear description. The main description only adds an example ('Delhi'), which is helpful but not substantial beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a city or country name to IANA timezone(s), using a specific verb 'Resolve' and a concrete example ('Delhi' -> 'Asia/Kolkata'). This distinguishes it from sibling tools that likely require exact timezone identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it first when you only have a place name,' providing clear guidance on when to use this tool. It also implies the alternative (knowing the exact identifier) by saying 'so you don't need the exact identifier.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It clearly indicates a read-only retrieval operation ('semantically search', 'return') with no mutation implied. It does not mention ordering, pagination, or error cases, but for a standard search tool the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first states the core function precisely, and the second adds helpful context ('retrieval half of RAG'). No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the absence of an output schema, and the lack of annotations, the description provides sufficient context: it explains what the tool does, the namespace concept, and the RAG relationship. It could mention return format details, but 'most relevant stored entries' is adequate for an agent to understand the expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all three parameters (query, top_k, namespace) with 100% coverage. The tool description does not add new parameter-level detail beyond what the schema states, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('semantically search'), a clear resource ('memory collection (namespace)'), and the outcome ('return the most relevant stored entries'). It also distinguishes itself from siblings like memory_upsert by calling itself 'The retrieval half of RAG,' making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'The retrieval half of RAG' implies this tool is for retrieval tasks and suggests a complementary relationship with memory_upsert. However, it does not explicitly state when not to use it or name alternatives, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the specific outputs (UTC offset, zone abbreviation, DST status) and the real-time 'now' nature, which is useful behavioral context. It does not discuss error handling or invalid timezone behavior, but for a simple read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose and followed by usage guidance. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a well-described schema and clear purpose, the description adequately states what it does, when to use it, and what information it returns. Minor gaps like explicit return structure or error behavior are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the timezone parameter with format and examples (100% coverage). The description adds no additional parameter-specific detail beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get the current local time in an IANA timezone'. It also lists the included details (UTC offset, zone abbreviation, DST), distinguishing it from sibling tools like convert_timezone by emphasizing 'now'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use whenever you need to know what time it is now somewhere.' This gives a clear context for when to use, though it does not explicitly name alternatives or exclusions, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses asynchronous behavior ('Returns immediately with a job_id'), retry semantics ('keeps retrying in the background until it succeeds'), and delivery guarantee. This adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action, and every clause adds value (methods, payload type, delivery guarantee, async return, retry behavior). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does well to explain expected return behavior (job_id) and asynchronous execution. It does not detail how to check delivery status, but that may be covered by sibling tools. Overall, it provides sufficient context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 properties have descriptions). The description's mention of methods ('POST/PUT/PATCH') and 'JSON payload' correlates with schema fields but does not add significant new parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deliver a webhook (POST/PUT/PATCH a JSON payload to a URL)'. It uses a specific verb and resource, and distinguishes itself from sibling tools (which are mostly about time, conversion, extraction, etc.) by focusing on webhook delivery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use this tool to fire webhooks with guaranteed delivery. It does not explicitly mention alternatives or when-not-to-use, but given its unique role among siblings, the context is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'shortens a URL' by stating that the resulting link redirects to the original and that codes are stored for a year, which is a meaningful retention policy. It does not specify whether the operation is idempotent or describe response format, but the core side effects are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose. Every word contributes meaningful information (shortening, output format, redirect behavior, retention). There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one parameter, and no output schema. The description covers the key purpose, behavior, and lifecycle (one-year storage). It does not explicitly state what the API returns, but that is reasonably inferred from the wording 'into a compact link.' This is adequate for the tool's complexity, though slightly more detail on the response could make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'url' with a description and format (uri). The tool description adds no additional parameter semantics beyond what the schema states. Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Shorten a long URL into a compact api.agishub.com/s/<code> link that redirects to the original.' It names a specific verb (shorten), a specific resource (long URL), and describes the output format. No sibling tool has a similar purpose, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for when you need to shorten a URL. It does not explicitly discuss when not to use it or mention alternatives, but the simplicity of the tool and the clear purpose make the intended usage evident. No exclusions or alternative tools are needed for such a straightforward utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral nuance: days are calendar-based and DST-safe while hours and minutes are absolute, and it notes that diff can handle two different zones. However, it does not specify the output format/unit for diff, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense but well-structured sentence that front-loads the tool's purpose and packs in key clarifications with parentheticals. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not state what the return looks like (e.g., a datetime for add, or a duration unit for diff). It covers the operation semantics well but leaves the output contract underspecified for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how unit semantics work (calendar days vs absolute hours/minutes), which is not in the schema's enum listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Timezone-aware date arithmetic: add or subtract a duration to a datetime... or compute the difference between two datetimes' – a specific verb and resource, and it distinguishes itself from sibling conversion/current-time tools by focusing on arithmetic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly describes the operations (add/subtract/diff) and the context of timezone-awareness, but does not explicitly name alternatives or when-not-to-use cases. The scope is clear enough, yet no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the primary behavioral disclosure. It specifies the output type (numeric embedding vector) and adds the multilingual capability, which are meaningful traits. It does not describe internal model details or edge-case behaviors, but the core transformation is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the core action front-loaded. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter embedding tool with no output schema, the description is complete: it states purpose, output type, and applicable use cases. The multilingual note adds useful context without bloat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'text' has full schema description coverage (100%), and the tool description largely mirrors the schema's explanation. The description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Turn text into') and resource ('numeric embedding vector'), naming concrete use cases (semantic search, RAG, similarity). This clearly differentiates it from sibling text-processing tools like classify or summarize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by naming semantic search, RAG, and similarity as intended applications, but it stops short of explicitly contrasting with alternative tools or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of stating behavior. It discloses the return type ('inline SVG plus a data URI') and mentions adjustable options (size, margin, error-correction). It does not mention any side effects, which is acceptable for a pure generation tool, but slightly more detail (e.g., the data URI format) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, information-dense sentence. It leads with the action and output, then lists the configurable aspects. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward generation tool, the description covers the key aspects: purpose, input type, output format, and available options. Since the schema exhaustively documents parameters and there is no output schema to explain, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema, so the schema coverage is 100%. The description mentions the parameters in natural language ('selectable size, quiet-zone margin and error-correction level') but does not add new semantic information beyond what the schema already provides. Thus, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a QR code for any text or URL.' It uses a specific verb (Generate) and identifies the resource (QR code), with no ambiguity. It also specifies the output format, making it easy to distinguish from any even vaguely related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: whenever a QR code for text/URL is needed. There are no sibling tools in the list that generate QR codes, so no explicit alternatives are required. It doesn't provide exclusions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agishub-mcp MCP server](https://glama.ai/mcp/servers/agishub/agishub-mcp/badges/card.svg)](https://glama.ai/mcp/servers/agishub/agishub-mcp)

Score Badge

Copy to your README.md:

[![agishub-mcp MCP server](https://glama.ai/mcp/servers/agishub/agishub-mcp/badges/score.svg)](https://glama.ai/mcp/servers/agishub/agishub-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agishub/agishub-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server