Unfold It MCP Server

Official

by Unfold-it

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: v0.9.1
Disambiguation5/5
Each tool has a clearly distinct purpose, covering goal CRUD, claim management, clarification, plan import, analytics, and assessment lifecycle. No overlap in functionality, and descriptions make boundaries explicit.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_goal, list_goals, generate_skill_assessment). No deviations or mixed conventions.
Tool Count5/5
With 13 tools, the set is well-scoped for the domain. It provides comprehensive operations without being bloated or sparse, fitting the typical 3-15 range.
Completeness5/5
The tool surface covers the full lifecycle: goal creation, status tracking, listing, deletion; claim management; clarification handling; plan import; assessment generation, scoring, and capabilities; analytics; and resource categories. No obvious gaps for the domain.
Average 4.4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return data (status, progress) and a specific status value to check. It does not detail error behavior or confirm read-only nature, but for a simple retrieval tool, it is fairly 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 extremely concise with four sentences, each adding value: purpose, return fields, and usage guidance. Front-loaded and 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 the tool has one parameter, no output schema, and is straightforward, the description adequately covers purpose, return values, and a usage example. It could include an example or note on errors, but it is complete enough for a simple retrieval.
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?
Only one parameter (`goal_id`) with a schema description that already mentions it comes from `create_goal`. Schema coverage is 100%, so the description adds no new meaning beyond what the schema provides, yielding a baseline score of 3.
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 returns goal status and progress, listing specific return fields (who claimed, step completion, plan generation status, progress report link). It does not explicitly distinguish from siblings like `list_goals`, but the purpose is 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 description gives a concrete use case: check plan generation completion or monitor progress. It does not mention when not to use it or compare to siblings, but the provided context is helpful.
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 provided, so description carries full burden. It discloses optional AI enrichment and credit usage via enrich parameter, and mentions the return value (goal with claim link and enriched step list). However, it does not mention auth requirements, rate limits, or whether it modifies existing data (likely creates new). Adequate 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?
Three focused sentences: main action, context of use, and key options/return. No waste, efficient for AI agent consumption.
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 9 parameters and nested objects with no output schema, the description covers the essential behavioral context (input, enrichment, output). It does not detail all parameters (e.g., priority, goal_context), but those have schema descriptions. The high-level flow is clear.
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 56%. Description adds meaning about pre-formulated plans and enrichment options, but does not significantly enhance understanding beyond the schema's individual parameter descriptions. For instance, 'enrich' parameter is well-described in schema already. Baseline score 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?
Description clearly states it imports a pre-formulated plan with steps/substeps into Unfold, using the verb 'import' and specifying the resource. It distinguishes from siblings like create_goal by noting 'skips clarification entirely' and that it's for already structured plans from tools like Jira or Linear.
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?
Explicitly says 'Use this when you already have a structured plan (e.g. from Jira, Linear, or your own planning tool)' and notes it 'skips clarification entirely'. This provides clear context for when to use, though it could explicitly state alternatives (e.g., 'use create_goal for plans needing clarification').
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 were provided, so the description bears full responsibility. It implies a read operation but does not explicitly state read-only nature or disclose any side effects, impact on data, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and examples, making it easy to scan. It is relatively concise given the amount of information covered, though some repetition could be trimmed.
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?
Despite no output schema, the description thoroughly explains return values (KPIs, at-risk learners, funnels, resource engagement). Given 7 parameters and nested objects, it provides sufficient context for using the 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%; the description adds value by providing examples for groupBy, metadata, and other parameters, clarifying their use in context beyond the schema definitions.
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 gets aggregated analytics for goals, listing specific KPIs and breakdowns. It distinguishes from siblings like get_goal_status and list_goals by emphasizing aggregation and cohort metrics.
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 examples and explains when to use groupBy and metadata filters, giving clear usage context. However, it does not explicitly state when not to use this tool or contrast it with alternative siblings.
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 full burden. It discloses that questions are AI-generated and validated, the token is HMAC-signed and tamper-proof, scoring is stateless, and typed errors are returned. This is comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, output details, chaining, errors, and scope. It is front-loaded with the core purpose. While somewhat lengthy, each section earns its place and the overall clarity justifies the length.
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?
Given the tool's complexity (8 parameters, nested objects, chaining, error types, scope requirements) and no output schema, the description covers all necessary aspects: input, output format, validation, error handling, chaining with score_skill_assessment, and security requirements. An AI agent has sufficient information to select and invoke the tool correctly.
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 coverage is 100%, so baseline is 3. The description adds meaningful extra context for parameters like work_item_context (chaining role, strong grounding), difficulty_mix (defaults), band_thresholds (defaults), and typed errors. It does not add much for simple fields like skill, but overall adds 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 the tool generates a skill-proficiency assessment (MCQs) for a learner, specifying the output and chaining to score_skill_assessment. It distinguishes itself from siblings by naming the downstream tool and emphasizing its role in the assessment pipeline.
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 explicit context for when to use the tool (generating an assessment) and includes chaining guidance, error handling, and scope requirements. However, it does not explicitly state when not to use it or describe alternatives among siblings like get_assessment_capabilities.
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 provided, so description bears full burden. Discloses that include_steps is off by default for performance, implying a behavioral trade-off. Does not mention pagination limits, default ordering, rate limits, or authentication. Adequate 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?
Five sentences, front-loaded with main purpose, then filters, then use cases, then alternative tool. No redundant information, each 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?
Covers filtering options, use cases, and alternative tools. Does not describe output format or ordering, but no output schema exists. Adequate for a list endpoint with 9 optional parameters.
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 coverage is 100% with descriptions for all parameters. Description adds value by explaining 'at-risk detection' for inactive_days, providing example for metadata usage ('track=frontend'), and clarifying benefit of include_steps. Exceeds 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?
Clearly states 'List all goals in your org created via the API.' Identifies the resource (goals) and action (list). Explicitly differentiates from sibling get_analytics by noting 'For aggregate cohort metrics, use get_analytics instead.'
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?
Provides explicit use cases: 'see all learner goals, check progress across a cohort, find unused claim links, or identify learners who have gone inactive.' Also tells when not to use: 'For aggregate cohort metrics, use get_analytics instead.'
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?
Given no annotations, the description carries the full burden. It discloses that the tool invalidates a link and does not affect existing claims. However, it lacks details on idempotency, error behavior, or authentication requirements, which 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 description is extremely concise (two sentences) and effectively front-loaded with the action. Every sentence adds value without redundancy, making it easy for an agent to quickly understand.
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 is fairly complete. It covers purpose, usage, and a key behavioral caveat. It lacks explicit mention of return values or error cases, but these are less 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?
Schema coverage is 100% with a clear description for the only parameter (claim_token). The main description does not add additional parameter context beyond what the schema already 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 clearly states the action 'Invalidate a claim link' and the resource, distinguishing it from sibling tools that focus on goals and assessments. It specifies the exact effect and what it does not do, leaving no ambiguity about its purpose.
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 provides explicit guidance on when to use this tool ('if a link was sent to the wrong person or needs to be regenerated') and clarifies what it does not do ('Does not remove access from a user who already claimed the goal'), which helps the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: stateless and deterministic scoring, token contains answer key, tampered/expired tokens are rejected, idempotent via request_id. It also mentions facet aggregation, coverage field, error codes, and required scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (chaining, errors) and front-loads the main purpose. It is detailed but not verbose; every section adds value. A slightly more condensed version could be possible, but current structure is good.
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?
Given the tool's complexity (4 params, nested objects, no output schema), the description covers everything needed: return values, error handling, chaining instructions, facet aggregation, and required scope. It 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?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond schema: it explains assessment_token's source and chaining, but does not elaborate on parameters beyond what the schema already 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 clearly states the tool's purpose: scoring a skill assessment using answers and the assessment_token from generate_skill_assessment. It specifies the resource (skill assessment) and action (score), and distinguishes it from siblings like generate_skill_assessment and create_goal.
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 explicit usage context: it must follow generate_skill_assessment, explains chaining into create_goal, and describes stateless, deterministic behavior. It does not explicitly exclude alternative tools, but the context is clear enough.
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 provided, so description carries full burden. Describes return values and required scope. Does not disclose idempotency or lack of side effects, but for a read-only introspection tool, the description is adequate.
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?
Concise with three front-loaded sentences, each adding value: purpose, specific return fields, and usage guidance.
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?
With no output schema, the description compensates by listing key return fields. Also mentions required scope. Complete for an introspection 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?
No parameters; description states 'No parameters required', which adds clarity. Baseline for zero parameters is 4.
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?
Clearly states it returns supported parameters for skill assessments, listing specific items. Distinguishes from siblings like generate_skill_assessment and score_skill_assessment.
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?
Explicitly instructs to use this before calling generate_skill_assessment, providing clear context. Does not explicitly mention when not to use, but the directive is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly discloses behavioral traits: returns a claim link, async plan generation (15-30s), auto_respond behavior, chaining, typed errors, warnings, and idempotency via request_id. This is comprehensive and exceeds expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections for CHAINING, TYPED ERRORS, and WARNINGS. It front-loads the core purpose. Every sentence adds value, though slight trimming could improve conciseness. Still, it is effectively organized.
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?
Given the complexity (14 parameters, nested objects, no output schema), the description is very complete. It explains the return value (claim link), async behavior, error handling, warnings, and idempotency. Without an output schema, it still provides sufficient response details.
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 86% (high), so baseline is 3. The description adds significant value beyond the schema, especially for the assessment parameter (explicitly explaining how to use it with chaining and types) and other parameters like auto_respond and request_id. The extra context justifies a 4.
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 it creates a goal with an AI-generated plan and returns a claim link. It is distinct from sibling tools like get_goal_status and delete_goal. The verb 'create' and resource 'goal' are specific, and the additional feature 'with AI-generated plan' adds clarity.
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 when to use (creating a goal for one user) and chaining information with assessments. It mentions alternatives like submit_clarification and advises calling once per learner. However, it does not explicitly compare to all siblings like import_plan or list_goals.
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 provided; description carries full burden. It clearly states the tool retrieves suggestions with confidence and reasoning, implying no destructive behavior, but does not explicitly mark it as read-only.
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?
Three sentences, each valuable: first defines purpose, second gives usage timing, third explains follow-up action. 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?
Covers purpose, usage context, and follow-up. Lacks detail on output format (e.g., confidence levels) but sufficient for a simple read 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 coverage is 100% with description for goal_id. Description adds context that goal_id comes from create_goal, enhancing schema meaning.
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?
Specific verb 'Get' with resource 'pending clarification questions for a goal', and distinguishes from siblings like submit_clarification and get_goal_status.
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?
Explicitly states when to use this tool ('after create_goal with auto_respond=false') and what to do next ('use submit_clarification to accept or override').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, fully discloses soft delete default, hard_delete option, scoping to API-created goals, idempotency, and superadmin restoration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with core action. Each sentence adds value, though could be slightly more concise.
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?
Covers behavior, constraints, and use cases well. Lacks mention of return value, but deletion often returns minimal info. Still fairly complete.
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 coverage is 100%, baseline 3. Adds context beyond schema: explains goal_id as UUID from create_goal and hard_delete implications.
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?
Clearly states 'Delete a goal created via the API' with specific verb and resource. Distinguishes from siblings like create_goal and list_goals.
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?
Explicitly describes when to use (regenerating after retake) and when not (goals created in webapp UI). Provides alternatives and notes idempotency.
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 that categories affect resource providers, content safety policies, and plan generation behavior. The examples illustrate specific behavioral differences. This is sufficient for a read-only list tool.
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 concise and well-structured. The first sentence states the core purpose, followed by usage details, then examples. Every sentence is informative with no redundancy.
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?
Given no parameters and no output schema, the description provides complete context: what the tool returns, how it is used, and example behavior differences. It is fully adequate for an agent to select and invoke the 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?
The tool has no parameters, so the baseline is 4. The description adds value by explaining the meaning and usage of the output (categories), even though it doesn't explain parameter behavior.
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 'List' and clearly identifies the resource as 'available resource categories for goal classification'. It distinguishes from siblings like create_goal and list_goals by directly stating the categories are used in those tools. The examples further clarify the purpose.
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 states when to use the tool: before create_goal or list_goals to inform category choices, and to build adaptive UIs. It provides context for alternative usage and implies when not needed (if categories are already known).
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 provided, so description carries full burden. It discloses asynchronous plan generation and how to monitor status. Could mention if answers are mutable or if re-submission is allowed, but overall good.
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?
Three concise paragraphs. First sentence immediately conveys purpose. Every sentence adds value without redundancy.
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?
Covers the full workflow: prerequisite (create_goal), parameter usage, async behavior, and follow-up check. No output schema needed for this 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 coverage is 100%. Description adds meaning: explains answers are for overriding, accept_agent_answers keeps suggestions, goal_id comes from create_goal. Adds context beyond schema.
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 'Submit answers to clarification questions and trigger plan generation', using a specific verb and resource. It distinguishes from sibling tools like get_clarification and create_goal.
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?
Explicitly says 'Use after create_goal with auto_respond=false' and explains when to use accept_agent_answers. Also provides follow-up steps using get_goal_status.
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:

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

Score Badge

Copy to your README.md:

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

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/Unfold-it/unfoldit-mcp-server'

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