Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/personal. Endpoint unchanged: https://mcp.moltlinestudio.com/personal — still live, still free on the free tier. Only this duplicate entry is deprecated.
20 personal-assistant persona and skill products plus deterministic everyday planners over MCP: budget_split (customizable 50/30/20), savings_goal with optional interest, spaced_repetition_plan review schedules, tip_split, countdown_days, and get_free_skill loading any product's complete free gateway skill.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: 'errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"}' and 'Every call is read-only and idempotent, so after correcting the input it is always safe to retry.' This provides error handling patterns and retry safety 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 a paragraph of several sentences, front-loaded with the main purpose and a concrete example. It includes the extraneous 'FREE' but is otherwise efficient. The error handling and differentiation are integrated naturally. Slightly more brevity could be achieved, but it's well-structured and 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 the tool's complexity (4 params, 1 required, no nested objects) and that an output schema exists (so return values need not be explained), the description is complete. It covers purpose, usage, error handling, default behavior, and distinguishes from siblings. The example output provides clarity. All necessary information for an agent to correctly select and invoke the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds meaning by stating 'Defaults to the 50/30/20 rule, fully customizable' and providing a typical input/output example. This clarifies the default behavior and shows how the parameters relate to the output, adding value beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Split monthly income into needs/wants/savings buckets with weekly equivalents.' It specifies the default 50/30/20 rule and explicitly distinguishes from the sibling 'savings_goal' by stating 'Not for how long a target takes to reach (savings_goal).' This provides a specific verb-resource combination and differentiates from alternatives.
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 monthly income needs allocating across buckets. Not for how long a target takes to reach (savings_goal).' It names the alternative tool (savings_goal) and provides guidance on error handling: 'on invalid input this tool never raises a protocol error — it returns an error object... safe to retry.' This clearly tells when and when not 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.
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?
The description adds significant value beyond annotations: it explains the free tier, input format with example, output format with example, per-event error handling (doesn't fail whole call), error response format, and explicitly states read-only and idempotent behavior. Annotations already provided readOnlyHint=true and idempotentHint=true, but the description adds rich context about error handling and retry safety.
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 clear sections: purpose, example, usage notes, error behavior. It is reasonably concise but could be slightly tighter; the error handling explanation is a bit verbose. However, it front-loads the key info ('Count the days until each named event') and earns its sentences.
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 (1 parameter, 100% schema coverage, output schema present, annotations present), the description is complete. It covers purpose, input/output examples, error handling, usage boundaries, and safety guarantees. No gaps remain for an AI 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?
The description provides a concrete example of the events parameter ('{"Launch": "2026-10-01", "Trip": "2026-09-05"}') and explains the limit ('The first 30 events are used'). Since schema coverage is 100% and the schema already describes the parameter, the description's example adds value by showing the exact format, though it doesn't elaborate on all edge cases (e.g., what happens with duplicate event names).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Count the days until each named event, soonest first' with a specific verb ('Count') and resource ('days until named events'). It distinguishes itself from siblings by mentioning 'Not for working-day math' (business_days) and 'not for building a review schedule' (spaced_repetition_plan).
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 clear usage guidance: 'Use to rank named dates by how soon they arrive' and explicitly states when not to use it ('Not for working-day math... not for building a review schedule') with named alternatives (timeops server's business_days, spaced_repetition_plan). It also includes error handling instructions and retry safety.
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, idempotentHint, and destructiveHint=false. The description adds critical behavioral context: the tool never raises protocol errors but returns an error object on invalid input, and it is idempotent ('after correcting the input it is always safe to retry'). 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 efficiently structured: a single-sentence summary, example, then details on behavior, when to use, differentiation from sibling, error handling, and idempotency. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 parameter, simple response) and the presence of an output schema, the description covers all necessary aspects: input format, output structure, error handling, and usage context. It is fully self-contained for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to compensate heavily. The description reiterates that slug must come from list_products and provides an example, but adds only modest context beyond the schema (e.g., 'chosen automatically from the slug'). 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 'Load' and specific resource 'product's free gateway skill with its complete instructions'. It distinguishes from sibling 'get_full_skill' by noting this returns only the free gateway skill chosen automatically from the slug, whereas the sibling requires a skill name and a paid plan. The example output and typical use case reinforce clarity.
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 says 'Use when the caller wants usable instructions immediately' and 'Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan.' Additionally, it guides error recovery by referencing list_products. This provides a clear decision framework for the agent.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description goes beyond by explaining error handling behavior: 'this tool never raises a protocol error — it returns an error object with fix instructions.' Also confirms read-only and idempotent nature. Adds concrete behavioral context not in 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 front-loaded with the main purpose in the first sentence. It includes a compact example, explicit usage guidance, and error behavior—all in about 120 words. Every sentence adds value with no redundancy.
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 appropriately provides a typical return structure without over-explaining. It covers all key aspects: purpose, usage boundaries, error handling, licensing context, and sibling differentiation. The description is fully sufficient for an agent to correctly decide 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% and the description provides an example input and output shape, adding real-world context. It also specifies that slug should be 'exactly as returned by list_products', giving the agent a clear source for valid values 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 uses specific verb 'Load one product in full' and clearly identifies the resource: 'its persona plus every paid skill'. It explicitly mentions 'PREMIUM (license)' and distinguishes from siblings by naming get_full_skill, list_products, and get_free_skill.
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?
Provides explicit when-to-use: 'Use when the caller wants the whole product.' And when-not: '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.' This is direct and references sibling tools.
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 declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these traits and adds the error handling pattern: 'never raises a protocol error — it returns an error object.' This adds context beyond annotations, though the core behavior is already covered.
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 front-loaded purpose, example, usage guidance, error handling, and idempotence note. While every sentence adds value, there is minor redundancy; it could be slightly more concise.
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 (2 parameters, no nested objects, output schema exists), the description covers purpose, usage, error behavior, idempotence, and references to sibling tools. It is complete for agent 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?
Schema description coverage is 100%, so baseline is 3. The description adds an example but does not provide new meaning beyond the schema's existing parameter descriptions (slug and skill_name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Load one paid skill's complete instructions from a product' – a specific verb (Load) and resource (paid skill's instructions). It distinguishes from siblings by naming get_free_skill and get_full_product, clarifying what this tool is not for.
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 says 'Use when the caller wants one specific paid skill' and lists alternatives: 'Not for the free gateway skill, which get_free_skill returns... not for every skill at once (get_full_product).' This provides clear when-to-use and 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.
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?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: 'Returns metadata only - no persona text and no skill instructions,' 'it never raises a protocol error — it returns an error object,' and 'Every call is read-only and idempotent, so after correcting the input it is always safe to retry.' This significantly enhances transparency.
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 clear lead sentence, followed by input/output details, usage guidance, and error handling. While slightly verbose, every sentence adds value and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, output schema exists), the description covers all relevant aspects: purpose, input, output structure, return behavior, error handling, and usage guidelines. It is complete and leaves no ambiguity.
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 confirms this with 'Takes no arguments.' Schema coverage is 100%, so the description adds no further parameter details but is clear and accurate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List every product in the Personal Suite line with its included skills.' It also distinguishes from siblings by noting that it returns metadata only, not skill instructions, and that the returned slug values are used with other tools like get_free_skill, get_full_product, and get_full_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly specifies when to use the tool ('when the caller wants to see what this server covers') and when not to ('Not for keyword search across the whole 138-product catalog... not for instructions the caller can act on'). It also provides an alternative: 'search_catalog' from the catalog server.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating 'Every call is read-only and idempotent', 'never raises a protocol error', returns an error object, and includes disclaimers like 'FREE' and 'not financial advice'. 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 fairly concise, front-loading the main purpose. All sentences are informative and avoid redundancy. It could be slightly more structured, but overall it is efficient and clear.
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 an output schema present, the description need not explain return values. It covers error handling, idempotency, read-only nature, usage guidance, sibling differentiation, and includes an example. The description is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description includes a typical input example but does not add new semantic details beyond the schema's parameter descriptions. It meets the baseline but does not go significantly beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Compute months to reach a savings target at a monthly contribution.' It clearly distinguishes from siblings by stating that it is not for budget_split or loan_payment, making the purpose 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?
Explicitly states when to use ('Use when a target amount and a monthly contribution are known'), provides exclusions ('Not for allocating income across categories... not for loan repayment'), and mentions that the tool is safe to retry after errors, 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.
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?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavior beyond that: it specifies the exact interval sequence (1, 3, 7, 14, 30, 60, 120, 240 days), shows a typical request/response pair, and explains that errors are returned as an 'error' object rather than a protocol error, with an example of the error message format. It also clarifies retry safety after correcting input, which is practical guidance not present in 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 front-loaded with purpose, followed by a concrete example, usage guidance, and error behavior. It is longer than strictly necessary and slightly repeats annotation info (read-only/idempotent), but every section serves a distinct purpose and the structure is logical. It is not bloated and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, typical input/output, usage boundaries, error handling, and safety semantics. An output schema exists, so return values are not needed, but the description gives an example anyway. There are no significant gaps for an agent to misuse 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 description coverage is 100% for both parameters, with clear descriptions for start_date and sessions, including the clamping range and default. The description's example input/output adds illustrative context but does not add new semantic detail beyond the schema. The baseline of 3 applies because the schema carries the parameter documentation burden, and the description does not materially enhance parameter understanding.
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 opens with a specific verb and resource: 'Build a spaced-repetition review schedule with expanding intervals.' It clearly differentiates from the educator server's lesson_timer by stating it is not for timing a single session, which is a useful distinction even though lesson_timer is not a sibling in the provided list.
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?
Explicit when-to-use: 'Use when material must be reviewed on expanding intervals.' Also explicit when-not-to-use and alternative: 'Not for timing a single session, which the educator server's lesson_timer handles.' This gives the agent clear decision criteria.
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?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: it confirms the tool is read-only and idempotent, and explicitly describes the error behavior (returns an error object instead of raising protocol errors). This aligns with and enriches the annotations without 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 concise and well-structured: it opens with a clear purpose, includes a representative example, covers usage boundaries, and explains error handling—all in a few sentences. Every sentence adds necessary information without redundancy.
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, 1 required, output schema exists), the description covers all essential aspects: purpose, input example, usage guidelines, behavioral guarantees (read-only, idempotent), and error handling. It is fully sufficient for an 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?
The input schema already has 100% description coverage for all three parameters, so the baseline is 3. The description adds value by providing a typical example input and output, which helps the agent understand how parameters map to behavior. It also mentions error handling that references parameter constraints. However, it does not add new parameter-level details beyond what the schema provides, so a 4 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 tool's purpose with a specific verb+resource ('Compute the tip and per-person split for a bill') and provides a concrete example. It explicitly distinguishes this tool from the sibling 'budget_split' by stating when not to use it, making the purpose 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 gives explicit guidance on when to use the tool ('Use for one bill shared among a group') and when not to use it ('Not for recurring household budgeting'), naming the alternative sibling tool 'budget_split'. It also explains error handling and retry safety, providing complete usage context.
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!
Add one secure layer between your agents and this server.
Each tool targets a distinct task: budget_split for income allocation, tip_split for bill splitting, savings_goal for target saving, etc. There is slight potential confusion between budget_split and tip_split as both involve splitting money, but their inputs and purposes (monthly income vs. a single bill) are clearly differentiated. No two tools have overlapping functionality.
Tool names follow a consistent snake_case verb_noun pattern (budget_split, tip_split, savings_goal, list_products, get_free_skill, etc.). The only minor inconsistency is that two tools use 'split' (budget_split, tip_split), which is fine as they refer to different kinds of splitting. Overall, the naming is predictable and clear.
With 9 tools, the count is perfectly scoped for a personal suite covering personal finance (budget_split, tip_split, savings_goal), product browsing (list_products, get_free_skill, get_full_product, get_full_skill), time utilities (countdown_days), and learning (spaced_repetition_plan). Each tool serves a clear purpose without bloat or triviality.
The tool set covers the advertised areas: personal finance budgeting, goal saving, bill splitting, product discovery, countdowns, and spaced repetition. A minor gap is the lack of an update or delete tool, but this is acceptable since the server is primarily read-only and informational. The product tools provide a reasonable lifecycle (list, get free, get full, get skill).