20 inbox, calendar, travel, meals and family-logistics skill products. 7 of 9 free.
Split monthly income into needs/wants/savings buckets with weekly equivalents. FREE.
Defaults to the 50/30/20 rule, fully customizable. Typical input {"monthly_income": 4000} returns {"needs": {"pct": 50, "monthly": 2000.0, "weekly": 461.54}, "wants": {...}, "savings": {...}, "note": "..."}.
Use when monthly income needs allocating across buckets. Not for how long a target takes to reach (savings_goal). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "monthly_income must be > 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| needs_pct | No | Percentage for needs; all three percentages must sum to 100. Default 50. | |
| wants_pct | No | Percentage for wants. Default 30. | |
| savings_pct | No | Percentage for savings. Default 20. | |
| monthly_income | Yes | Take-home monthly income; must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces these by stating 'Every call is read-only and idempotent, so after correcting the input it is always safe to retry.' It also adds the error return behavior, which is not covered by annotations. The mention of 'FREE' is extraneous, but overall the description adds meaningful context beyond 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 approximately 120 words, highly focused, and front-loaded. The first sentence states the primary purpose. Each subsequent sentence adds distinct value: defaults, example, usage guidance, error handling, and safety. No redundant or unnecessary wording.
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 the tool's moderate complexity (4 parameters, 1 required, full schema coverage, output schema present, rich annotations), the description covers purpose, usage differentiation, error behavior, idempotency, and provides a concrete example. It addresses all key aspects an agent needs to correctly invoke the tool, leaving no obvious gaps.
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 input schema already documents all parameters with descriptions and defaults. The description adds a typical input example and mentions the '50/30/20 rule', which provides context but does not significantly enhance understanding 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'split' and the resource 'monthly income', and provides a concrete example of the output format. It also explicitly distinguishes itself from the sibling tool 'savings_goal' by stating 'Not for how long a target takes to reach (savings_goal)'. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Use when monthly income needs allocating across buckets') and when not to use it, naming the specific alternative ('savings_goal'). It also provides error handling guidance, stating that the tool never raises protocol errors but returns a structured error object, which helps the agent decide to retry after correcting input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count the days until each named event, soonest first. FREE.
Typical input {"events": {"Launch": "2026-10-01", "Trip": "2026-09-05"}} returns {"today": "YYYY-MM-DD", "events": [{"event": "Trip", "date": "2026-09-05", "days_away": 20}, ...]}; a bad date gets a per-event error entry instead of failing the whole call.
Use to rank named dates by how soon they arrive. Not for working-day math, which the timeops server's business_days handles, and not for building a review schedule (spaced_repetition_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | Mapping of event name to ISO date YYYY-MM-DD, e.g. {"Launch": "2026-10-01"}. The first 30 events are used. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating 'Every call is read-only and idempotent' and detailing error behavior: 'a bad date gets a per-event error entry' and 'on invalid input never raises a protocol error — it returns an error message'. No contradictions.
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 well-structured: a one-line purpose, a typical input/output example, usage guidelines, and error handling. Every sentence adds value, and it is concise without being overly long.
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 the single parameter and the presence of an output schema, the description covers input format, output format with sample, error handling, limit of 30 events, and comparisons to sibling tools. It is fully complete for the agent to use this 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?
Schema coverage is 100% and the schema description already includes the limit of 30 events. The description goes further by providing a concrete input/output example, clarifying the return format with per-event error entries, and explaining the error structure. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Count the days until each named event, soonest first.' It gives a typical input/output example and explicitly distinguishes from siblings like 'business_days' and 'spaced_repetition_plan', making the tool's specific purpose 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?
It explicitly says 'Use to rank named dates by how soon they arrive' and provides exclusions: 'Not for working-day math...' and 'not for building a review schedule...', naming alternatives. It also explains error handling behavior, guiding the agent on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a product's free gateway skill with its complete instructions. FREE.
Typical input {"slug": "inbox-assistant"} returns {"slug": ..., "skill": "", "instructions": ""}.
Returns exactly one skill - the product's free gateway skill - chosen automatically from the slug, with no plan required. Use when the caller wants usable instructions immediately. Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''. Use list_products."}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "inbox-assistant". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: it explains that the tool never raises protocol errors but returns an error object with fix guidance, that it always returns exactly one skill chosen automatically, and that every call is read-only and idempotent. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured in three paragraphs: purpose (with example), sibling distinction, and error/behavioral details. Every sentence earns its place. A slight reduction from 5 because the example could be integrated more tersely, but overall concise and 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?
Given the presence of an output schema (indicated by context signals), the description does not need to detail return fields. It adequately covers the return shape (slug, skill, instructions), error format, usage boundaries, and safety. For a single-parameter tool with full annotations and an output schema, the description is fully 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% (one parameter with a clear description). The description adds a typical input example but does not provide additional semantic constraints or format details beyond what the schema already includes. Baseline score 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb-resource pairs: 'Load a product's free gateway skill with its complete instructions.' It clearly identifies the tool's unique scope (free gateway skill) and distinguishes it from the sibling get_full_skill by stating 'Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan.' The example further clarifies the return structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('Use when the caller wants usable instructions immediately.') and when not to use ('Not for the product's other skills'), naming the alternative tool (get_full_skill) and its prerequisites (paid plan). It also explains error handling and retry safety, guiding the agent on correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one product in full: its persona plus every paid skill. PREMIUM (license).
Typical input {"slug": "inbox-assistant"} returns {"slug": ..., "name": ..., "persona": "", "skills": [{"name": ..., "instructions": ...}, ...], "free_skill": {...}}.
Returns persona plus every skill for one product. Use when the caller wants the whole product. Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "inbox-assistant". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses error handling behavior: 'on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ...}.' It also mentions the 'PREMIUM (license)' prerequisite, adding useful context without contradicting 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 well-structured, front-loading the core purpose, then providing a concrete example, usage guidance, error handling, and idempotency note. It is efficient, though a few phrases could be trimmed without losing 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?
Given the simplicity of the tool (one parameter, comprehensive annotations, output schema exists), the description covers purpose, usage, errors, and idempotency. The mention of 'PREMIUM (license)' is brief but sufficient for context. Overall, it provides enough information for an agent to use 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?
The input schema already describes the 'slug' parameter with high coverage (100%). The description adds a typical input example and shows the output shape, but does not significantly extend the semantic meaning of the parameter itself. Baseline 3 is appropriate as schema does the heavy lifting.
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 states the tool's purpose: 'Load one product in full: its persona plus every paid skill.' It uses a specific verb ('load') and resource ('product'), and explicitly distinguishes from sibling tools like get_full_skill and get_free_skill, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use when the caller wants the whole product.' It also specifies when not to use it, naming alternative tools: 'Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one paid skill's complete instructions from a product. PREMIUM (license).
Typical input {"slug": "inbox-assistant", "skill_name": "Zero Sweep"} returns {"slug": ..., "skill": ..., "instructions": ""}.
Returns one named skill, selected by skill_name. Use when the caller wants one specific paid skill. Not for the free gateway skill, which get_free_skill returns with no plan, and not for every skill at once (get_full_product). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products. | |
| skill_name | Yes | Exact skill name as listed in that product's "skills" array from list_products. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool returns an error object instead of raising protocol errors, and confirms idempotency and retry safety. No contradiction.
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 well-structured: first sentence states purpose, then example, then usage guidance, then error behavior, then safety note. It is concise, front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers purpose, usage, error handling, and safety. It is fully complete for a read-only, idempotent tool with clear error responses.
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 are fully described in the schema (100% coverage). The description adds an example with specific values, explains constraints (slug from list_products, skill_name from skills array), and provides error handling context.
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 states the verb 'Load' and the resource 'one paid skill's complete instructions from a product'. It differentiates from siblings by explicitly naming get_free_skill and get_full_product, and provides an example input/output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the caller wants one specific paid skill' and 'Not for the free gateway skill... not for every skill at once'. It also covers error handling and retry safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every product in the Personal Suite line with its included skills. FREE.
Takes no arguments. Returns a list of 20 product objects, each {"slug": "inbox-assistant", "name": ..., "tagline": ..., "skills": ["Skill A", ...], "free_skill": "Gateway Skill Name"}. Use the returned slug values with get_free_skill, get_full_product, or get_full_skill.
Returns metadata only - no persona text and no skill instructions. Use when the caller wants to see what this server covers. Not for keyword search across the whole 138-product catalog, which the catalog server's search_catalog does, and not for instructions the caller can act on (get_free_skill). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: confirms read-only and idempotent nature (matching annotations), specifies that it returns metadata only (no persona or skill instructions), and explicitly describes error handling behavior (never raises protocol error, returns error object). This goes beyond what annotations provide.
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 several sentences long but every sentence adds value: purpose, input, output structure, use cases, exclusions, error handling. It is front-loaded with the primary purpose and free status. Slightly longer than strictly necessary, but highly informative.
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 zero parameters, strong annotations, and the presence of an output schema, the description covers everything an agent needs: what the tool returns, how to use the returned data, when to call it, and error behavior. It is fully complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description explicitly states 'Takes no arguments.' With no parameters to document, the baseline is 4, and the description handles it appropriately without needing to add param details.
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 states the verb 'list' and the resource 'every product in the Personal Suite line with its included skills'. It distinguishes from sibling tools like get_free_skill, get_full_product, and get_full_skill by noting that this tool returns only metadata and is for overview, not details or instructions.
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?
Explicitly states when to use ('Use when the caller wants to see what this server covers') and when not to use ('Not for keyword search... search_catalog' and 'not for instructions... get_free_skill'). Provides clear exclusions and alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute months to reach a savings target at a monthly contribution. FREE.
Optionally compounds interest monthly. Administrative math only — not financial advice. Typical input {"target": 10000, "monthly_saving": 400, "annual_rate_pct": 4} returns {"months": 24, "years": 2.0, "final_balance": 10021.94, "interest_earned": 421.94, "note": "..."}.
Use when a target amount and a monthly contribution are known. Not for allocating income across categories (budget_split) and not for loan repayment, which the business server's loan_payment computes. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "target and monthly_saving must be > 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The savings goal; must be greater than 0. | |
| monthly_saving | Yes | Contribution per month; must be greater than 0. | |
| annual_rate_pct | No | Annual interest rate percentage, 0 to 100, compounded monthly. Default 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds behavioral details: error handling ('never raises a protocol error — returns error object'), safety of retry, and the disclaimer that it is 'administrative math only — not financial advice.' This provides rich context that annotations alone do not.
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 (approx. 150 words) and well-structured: purpose, optional feature, example, usage guidance, error handling, idempotency. Every sentence serves a clear purpose. It is front-loaded with the main action.
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 the tool's simplicity (3 parameters, output schema exists), the description covers all needed aspects: input requirements, output format (via example), error behavior, idempotency, and differentiation from siblings. 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 coverage is 100%, so the baseline is 3. The description includes a typical example and mentions optional compounding, but does not add semantic meaning to the parameters beyond what the schema already provides (e.g., target >0, monthly_saving >0, annual_rate_pct 0-100). The example is helpful but not a semantic enhancement.
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 starts with a clear verb+resource: 'Compute months to reach a savings target at a monthly contribution.' It explicitly distinguishes itself from sibling tools budget_split and loan_payment, making the tool's unique scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use when a target amount and a monthly contribution are known.' It also clearly states what not to use it for (income allocation, loan repayment) and names the alternative tools (budget_split, loan_payment), giving the agent strong decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a spaced-repetition review schedule with expanding intervals. FREE.
Intervals follow 1, 3, 7, 14, 30, 60, 120, 240 days. Typical input {"start_date": "2026-09-01", "sessions": 4} returns {"start": "2026-09-01", "reviews": [{"session": 1, "day_offset": 1, "date": "2026-09-02"}, ...]}.
Use when material must be reviewed on expanding intervals. Not for timing a single session, which the educator server's lesson_timer handles. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "start_date must be YYYY-MM-DD"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| sessions | No | Number of review sessions; values outside 1-8 are clamped. Default 6. | |
| start_date | Yes | The day you learned the material, ISO YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing the error behavior ('never raises a protocol error'), the exact interval schedule, and the return format. It confirms the readOnlyHint and idempotentHint annotations with plain language, and adds that it's safe to retry after correction. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short opening, a code example, usage rules, and error handling. Every sentence adds value, but there is minor redundancy (e.g., the interval list and example overlap slightly). It could be trimmed slightly 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?
Given the tool's moderate complexity (2 params, simple output), the description fully covers purpose, usage, parameters, errors, and idempotency. The output schema exists, so the description doesn't need to detail return values. The combination of description, annotations, and schema is complete for effective use.
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 already covers both parameters with descriptions and defaults, so the baseline is 3. The description adds value by showing a concrete example input and output (e.g., 'sessions': 4 returns 4 review dates), and hints at clamping behavior. However, it does not fully explain the 'sessions' default or clamping range beyond what the schema states.
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 states the tool builds a spaced-repetition review schedule with expanding intervals, which is a specific verb+resource combination. It distinguishes itself from siblings by providing explicit interval details and a usage example, and none of the sibling tools appear to overlap with this functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('material must be reviewed on expanding intervals') and when not to ('not for timing a single session'), and names the alternative tool ('lesson_timer'). It also provides guidance on error handling and retry behavior, making usage boundaries exceptionally clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the tip and per-person split for a bill. FREE.
Typical input {"bill": 86.40, "tip_pct": 20, "people": 4} returns {"tip": 17.28, "total": 103.68, "per_person": 25.92}.
Use for one bill shared among a group. Not for recurring household budgeting (budget_split). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "bill must be > 0 and people >= 1"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| bill | Yes | The pre-tip bill amount; must be greater than 0. | |
| people | No | How many people split the total; at least 1. Default 1. | |
| tip_pct | No | Tip percentage, 0 to 100. Default 18. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces these with 'Every call is read-only and idempotent' and adds critical behavioral context about error handling: 'on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"}.' This goes beyond annotations to inform the agent about error recovery. No contradiction.
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 well-structured and each sentence adds value: purpose, example, usage guidance, and error behavior. It is slightly longer than necessary due to the example and the standalone 'FREE.' line, which is somewhat distracting but doesn't harm clarity. Overall, it is concise and front-loaded with the core purpose.
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 3 parameters (1 required), full schema coverage, annotations, and an output schema (evidenced by the example), the description is complete. It covers purpose, usage boundaries, error handling, safety profile, and example output. Nothing critical is missing for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds a concrete example showing typical input and output ('Typical input {"bill": 86.40, ...} returns {"tip": 17.28, ...}'), which helps the agent understand how parameters map to results, providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Compute the tip and per-person split for a bill,' which clearly states the verb and resource. It explicitly distinguishes from the sibling tool 'budget_split' by saying 'Not for recurring household budgeting (budget_split).' This meets the highest criteria for specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use for one bill shared among a group. Not for recurring household budgeting (budget_split).' This tells the agent exactly when to use this tool and when to use the alternative, satisfying the requirements for when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
budget_splitcountdown_daysget_free_skillget_full_productget_full_skilllist_productssavings_goalspaced_repetition_plantip_splitClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
20 blogging, brand-voice, copywriting, video and social skill products. 6 of 8 free.
30 finance, bookkeeping, legal-ops and SMB operations skill products. 6 of 8 tools free.
8 curriculum, classroom, accommodations and exam-prep skill products. 5 of 7 free.
7 outreach, sequencing, call-coaching and CRM-hygiene skill products. 6 of 8 free.
Add one secure layer between your agents and this server.
Most tools target distinct purposes (budgeting, counting days, skills, finances, scheduling, bill splitting). However, budget_split and savings_goal both deal with personal finance and could be confused by an agent, though their descriptions clarify the difference. Also, get_free_skill, get_full_skill, and get_full_product are related but clearly distinguished by access level and scope.
Tool names use a consistent snake_case verb_noun pattern (e.g., budget_split, countdown_days, savings_goal). The only minor deviation is that some verbs are adjectives (free, full) rather than actions, but the pattern is still predictable and readable.
With 9 tools, the set is well-scoped for a personal finance and productivity assistant. Each tool addresses a distinct, useful function without overwhelming the agent or leaving trivial gaps.
The tool surface covers key personal tasks: budgeting, savings goals, event countdowns, spaced repetition, bill splitting, and product exploration. A minor gap is the lack of a tool for expense tracking or recurring bills, but the domain is well-covered for the stated purpose.