Goal Story MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources (goals, steps, stories, scheduled stories, user) and actions (create, read, update, destroy), with no significant overlap. For example, goalstory_create_steps and goalstory_set_steps_order serve different functions (creating vs. reordering), and tools like goalstory_get_story_context and goalstory_read_stories are specialized for distinct aspects of story handling.
Naming Consistency5/5
All tools follow a consistent naming pattern: 'goalstory_' prefix, then a verb (e.g., create, read, update, destroy, get, set), and a noun (e.g., goal, step, story, scheduled_story, user). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or structure.
Tool Count3/5
With 25 tools, the count is borderline high for the domain of goal and story management. While it covers comprehensive operations, it may feel heavy and potentially overwhelming for agents, as many tools (e.g., multiple read and update variants) could be consolidated or streamlined without losing functionality.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for all core resources: goals, steps, stories, scheduled stories, and user profiles. It includes creation, reading, updating, and deletion operations, along with specialized tools for ordering, context gathering, and focus tracking, ensuring no obvious gaps for agent workflows in this domain.
Average 3.3/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a scheduling operation (implying a write/mutation) but doesn't mention permissions needed, whether scheduling is recurring or one-time, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is insufficient behavioral context.
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 a single, efficient sentence that front-loads the core purpose. Every word contributes meaning, though it could potentially be structured to separate purpose from parameter mentions for even better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'scheduling' entails (e.g., frequency, notification behavior), what the tool returns, or error scenarios. Given the complexity of scheduling operations, more contextual information would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description mentions 'goal ID and the desired time settings (hour and minute)' but adds no additional semantic context beyond what's in the schema (e.g., explaining that 'minute' is implied in timeSettings or clarifying timezone handling). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Schedule automatic story generation') and the target resource ('for a specific goal'), making the purpose evident. However, it doesn't explicitly differentiate this tool from its sibling 'goalstory_create_story' (which likely creates stories immediately rather than scheduling them), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'goalstory_create_story' or 'goalstory_update_scheduled_story'. It mentions required parameters but doesn't explain prerequisites, appropriate contexts, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'permanently removed' in the schema, but the description only says 'remove' without clarifying if this is irreversible, requires specific permissions, or has side effects (e.g., reordering remaining steps). This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficiently communicates the core purpose, earning its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It lacks critical context such as confirmation of success/failure, error conditions, or impact on related data (e.g., goal progress). This leaves significant gaps for safe agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the 'id' parameter fully documented in the schema itself. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('remove') and target ('a specific step from a goal's action plan'), making the purpose immediately understandable. It distinguishes from siblings like goalstory_destroy_goal (different target) and goalstory_update_step (different action), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., step must exist), exclusions (e.g., cannot remove steps in certain states), or sibling tools like goalstory_update_step for modifications instead of removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it's a read-only operation, potential side effects, authentication needs, rate limits, or response format. The phrase 'gather rich context' implies data retrieval, but without annotations, more explicit safety and operational context is needed.
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 concise and well-structured in two sentences, front-loading the main purpose. Every sentence contributes to understanding the tool's function without unnecessary fluff. However, it could be slightly more efficient by integrating the two sentences more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of gathering user context and the lack of annotations and output schema, the description is moderately complete. It explains the tool's purpose but misses details on behavioral aspects and usage context. For a tool with 3 parameters and no output schema, it should ideally provide more guidance on what the gathered context includes or how it's structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (goalId, stepId, feedback) with clear descriptions. The description adds minimal value beyond the schema by implying these parameters are used for 'context gathering' and 'enhancing understanding,' but it doesn't provide additional semantics like examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gather rich context about the user, their current goal/step, beliefs, and motivations to create deeply personalized and meaningful stories.' It specifies the verb 'gather' and the resource 'context' about user data and conversation insights. However, it doesn't explicitly differentiate from siblings like 'goalstory_read_one_goal' or 'goalstory_read_one_step', which might also retrieve user/goal data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions combining user profile data with conversation insights but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this should be used before story creation or as a standalone context-fetching tool compared to other read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a story for revisiting visualization and mental imagery, which implies a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core action ('retrieve a specific story') and purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and output format. Without annotations or output schema, more context on what 'retrieve' returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Unique identifier of the story to retrieve.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieve') and resource ('a specific story'), and specifies the purpose ('to revisit the visualization and mental imagery created for goal achievement'). It distinguishes this tool from siblings like 'goalstory_read_stories' (plural) by focusing on a single story, though it doesn't explicitly name alternatives. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'goalstory_read_stories' for multiple stories, 'goalstory_read_one_goal' for goals, or 'goalstory_get_story_context' for context. Usage is implied by the purpose but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update' implying mutation, but doesn't disclose behavioral traits such as required permissions, whether updates are reversible, error handling, or rate limits. The mention of 'story/belief modes that influence how stories are generated' hints at side effects, but this is vague. For a mutation tool with zero annotation coverage, this is insufficient.
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 a single, efficient sentence that front-loads the core action and lists key fields. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating core fields from side effects).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 8 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or important constraints like validation rules for fields. This leaves significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description lists the updatable fields (name, status, description, outcomes, evidence, story/belief modes), which aligns with the schema but adds no additional meaning beyond it. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('goal details'), and lists specific fields that can be updated (name, status, description, outcomes, evidence, story/belief modes). It distinguishes from sibling tools like goalstory_create_goal (creation) and goalstory_destroy_goal (deletion), but doesn't explicitly differentiate from other update tools like goalstory_update_scheduled_story or goalstory_update_step. This makes it clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing goal ID), exclusions (e.g., what fields cannot be updated), or comparisons to other update tools in the sibling list. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions updating configuration but doesn't describe what happens during the update (e.g., whether changes are immediate, reversible, or require specific permissions). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior and potential side effects.
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 a single, efficient sentence that front-loads the core purpose. It wastes no words but could be slightly more structured by separating the 'what' from examples. Overall, it's appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the update operation returns, error conditions, or behavioral implications. Given the complexity (3 parameters including nested objects) and lack of structured metadata, the description should provide more context about the tool's effects and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'time' and 'status' as updatable fields, but doesn't provide additional context beyond what's in the schema. This meets the baseline expectation when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('configuration of a scheduled story generation'), with specific examples of what can be changed ('time or its status'). However, it doesn't explicitly distinguish this tool from sibling tools like 'goalstory_update_goal' or 'goalstory_update_step', which could lead to confusion about when to use each update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing scheduled story), exclusions, or comparisons to sibling tools like 'goalstory_create_scheduled_story' or 'goalstory_destroy_scheduled_story'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that updating 'about' data involves guiding the user through questions, which adds some context about the interactive nature of that parameter. However, it lacks details on permissions required, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
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 concise and well-structured in two sentences. The first sentence front-loads the core purpose, and the second adds specific guidance for one parameter. There's no unnecessary repetition or fluff, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, side effects, or what the tool returns. The parameter guidance is minimal, and there's no mention of sibling tools or error conditions, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it implies that 'about' involves guided questions for gathering motivations and beliefs, which slightly elaborates on the schema's description. However, it doesn't provide additional syntax, format, or constraints for any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating the user's profile with specific fields (name, visibility preferences, personal context). It uses specific verbs ('update', 'guide') and identifies the resource ('user's profile'). However, it doesn't explicitly differentiate from sibling tools like 'goalstory_update_goal' or 'goalstory_update_step', which also perform updates on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that updating 'about' data involves guiding the user through questions, but it doesn't specify when to use this tool versus alternatives (e.g., 'goalstory_read_self_user' for reading the profile or other update tools for different resources). No explicit when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update step notes' implying a mutation, but lacks details on permissions, whether notes are appended or replaced, error handling, or response format. The mention of 'markdown format' adds some context, but behavioral disclosure is insufficient 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 concise with two sentences that are front-loaded and relevant. However, the second sentence ('Use this to capture...') could be more integrated into the first for better flow, and some redundancy exists with the schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with two parameters, the description is incomplete. It lacks details on behavioral traits, error cases, and response expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('id' and 'notes') well-documented in the schema. The description adds minimal value by reinforcing 'notes' as 'additional context, insights, or reflections in markdown format,' but doesn't provide new semantics beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 verb ('Update step notes') and the resource ('step notes'), specifying the content format ('markdown format') and purpose ('capture valuable information from discussions'). However, it doesn't explicitly differentiate from the sibling tool 'goalstory_update_step', which likely updates different step attributes beyond notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Use this to capture valuable information from discussions,' which implies usage for note-taking but offers no explicit when-to-use vs. alternatives, prerequisites, or exclusions. No comparison to sibling tools like 'goalstory_update_step' is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'creating a new goal' and suggests user interaction, but lacks details on permissions, whether creation is reversible, error handling, or what happens after saving. For a mutation tool with zero annotation coverage, this is insufficient behavioral disclosure.
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 appropriately sized with two sentences that convey key information without unnecessary fluff. It's front-loaded with the main action ('create a new goal'), though the second sentence could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (creates new data) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important behavioral aspects like idempotency or side effects, which are critical for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (name, description, story_mode, belief_mode) with clear descriptions. The description doesn't add any additional meaning or context about the parameters beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a new goal') and the resource ('goal'), making the purpose evident. However, it doesn't explicitly differentiate this from sibling tools like 'goalstory_update_goal' or 'goalstory_destroy_goal', which would require more specific language about when to create versus modify or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'begin the goal clarification process' and suggesting discussion with the user, which gives some context. However, it doesn't explicitly state when to use this tool versus alternatives like 'goalstory_update_goal' or provide clear exclusions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: steps are ordered by 'order_ts' timestamp in ascending order, array order determines sequence, and the tool involves user interaction (review and confirmation). However, it lacks details on permissions, rate limits, or what happens if steps are saved (e.g., creation vs. draft state), leaving gaps 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but could be more front-loaded. The first sentence states the purpose, but subsequent sentences mix usage notes and technical details (e.g., timestamp ordering), making it slightly verbose. It earns its place by covering multiple aspects, but the structure could be improved for clarity, such as separating purpose from behavioral instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description provides decent context for a mutation tool with 2 parameters. It covers the creation process, ordering logic, and user interaction, but lacks information on return values, error handling, or prerequisites (e.g., goal existence). This leaves some gaps in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('goal_id' and 'steps') well. The description adds some semantic context by emphasizing that steps should be 'clear and achievable' and that array order maps to step sequence, but this mostly reiterates schema details without significant extra meaning. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Formulate actionable steps for a goal through thoughtful discussion.' It specifies the verb ('formulate') and resource ('actionable steps for a goal'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'goalstory_set_steps_order' or 'goalstory_update_step', which also involve steps, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context about presenting steps for user review and confirming refinements, but it doesn't offer explicit guidance on when to use this tool versus alternatives. For example, it doesn't compare to 'goalstory_set_steps_order' for ordering steps or 'goalstory_update_step' for modifying steps, leaving the agent without clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves detailed information, which implies a read-only operation, but doesn't clarify aspects like authentication requirements, error handling (e.g., if the ID is invalid), rate limits, or what 'detailed information' includes (e.g., fields returned). This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, well-structured sentence that efficiently conveys the core purpose and context. It avoids redundancy and is appropriately sized for a simple retrieval tool, though it could be slightly more front-loaded by stating the action more directly (e.g., 'Retrieves detailed information...').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' entails (e.g., fields like title, status, dates), which is critical for an agent to understand the return value. Without annotations or an output schema, the description should provide more context about the response structure and any behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter clearly documented as a unique identifier. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('detailed information about a specific goal'), distinguishing it from siblings like 'goalstory_read_goals' (which likely lists multiple goals). However, it doesn't explicitly differentiate from 'goalstory_read_one_step' or 'goalstory_read_one_story', which have similar retrieval patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to support focused discussion and story creation'), suggesting when this tool might be beneficial. However, it lacks explicit guidance on when to use this versus alternatives like 'goalstory_read_goals' (for listing goals) or other read tools for steps/stories, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the purpose ('supporting reflection and motivation') but lacks critical details: whether this is a read-only operation, if it requires authentication, pagination behavior (implied by 'page' parameter but not explained), rate limits, or what the return format looks like. The description doesn't contradict annotations (none exist), but provides insufficient behavioral context for a tool with pagination parameters.
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 a single, well-structured sentence that efficiently communicates the core purpose. It's appropriately sized for a read operation with clear parameters, though it could be slightly more front-loaded by mentioning pagination support earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a paginated read operation with 4 parameters, the description is incomplete. It doesn't explain the return format (stories structure), pagination behavior (e.g., default page/limit values), error conditions, or authentication requirements. For a tool that returns collections, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain story format, pagination defaults, or relationship between goal_id and step_id). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Access the collection') and resource ('personalized stories created for a specific goal/step pair'), distinguishing it from siblings like goalstory_read_one_story (single story) or goalstory_read_scheduled_stories (scheduled stories). However, it doesn't explicitly contrast with goalstory_read_goals or goalstory_read_steps, which access different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('supporting reflection and motivation') and specifies the target ('for a specific goal/step pair'), but doesn't explicitly state when to use this tool versus alternatives like goalstory_read_one_story or goalstory_read_scheduled_stories. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Update' which implies mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or rate limits. The phrase 'track progress and insights' hints at usage but lacks operational details. For a mutation tool with zero annotation coverage, this is a significant gap.
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 two sentences, front-loaded with the core action and fields, followed by a usage hint. It's efficient with zero wasted words, though the second sentence could be more specific. Every sentence earns its place, but it's slightly brief for a mutation tool without annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error cases, or behavioral constraints, leaving gaps for an AI agent. With no output schema and zero annotation coverage, it should provide more context about what happens after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly (e.g., 'id' as unique identifier, 'status' with 0/1 values). The description lists the same fields (name, completion status, evidence, outcome) but doesn't add meaning beyond the schema, such as formatting examples or interdependencies. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('step details') with specific fields (name, completion status, evidence, outcome). It distinguishes from sibling tools like 'goalstory_update_step_notes' by focusing on core step attributes rather than just notes. However, it doesn't explicitly differentiate from other update tools like 'goalstory_update_goal' or 'goalstory_update_scheduled_story' at the resource level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'Use this to track progress and insights,' suggesting it's for updating step progress. However, it lacks explicit guidance on when to choose this over alternatives like 'goalstory_update_step_notes' or 'goalstory_set_steps_order,' and doesn't mention prerequisites or exclusions. The context is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'saves' the story (implying a write operation) and uses 'user discussion and profile data' for context, but doesn't disclose critical behavioral traits like authentication needs, rate limits, whether the story is editable, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap.
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 efficiently structured in two sentences: the first states the core purpose, and the second adds context-gathering behavior. It's front-loaded with the main action and avoids redundancy. However, the second sentence could be slightly more concise by integrating context gathering into the first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 4 required parameters) and lack of annotations or output schema, the description is moderately complete. It covers the purpose and context gathering but misses details like return values, error handling, or side effects. For a tool that creates and saves data, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters (goal_id, step_id, title, story_text) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate and save a highly personalized story that visualizes achievement of the current goal/step.' It specifies the action (generate and save) and resource (story for goal/step), distinguishing it from siblings like goalstory_read_stories or goalstory_destroy_scheduled_story. However, it doesn't explicitly differentiate from goalstory_create_scheduled_story, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'If context is needed, gathers it through user discussion and profile data,' suggesting it's used when personalized visualization is required. However, it lacks explicit guidance on when to use this tool versus alternatives like goalstory_create_scheduled_story or goalstory_get_story_context, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the destructive nature ('Delete') and adds a caution ('Use with confirmation'), but it lacks details on permissions, reversibility, side effects, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in 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 two short sentences with zero waste: the first states the purpose, and the second provides a usage note. It is appropriately sized and front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It should cover more behavioral aspects like confirmation details, error handling, or what happens post-deletion. The current description leaves too many contextual gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter fully documented. The description does not add any semantic details beyond what the schema provides (e.g., format examples or constraints), so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a scheduled story generation configuration'), which is specific and unambiguous. It distinguishes from siblings like 'goalstory_destroy_goal' or 'goalstory_destroy_step' by specifying the exact resource type, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use with confirmation,' which implies a cautionary context for this destructive operation, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., vs. 'goalstory_update_scheduled_story' for modifications) or any prerequisites. This leaves usage somewhat implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieving 'detailed information' but doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'read' in name), what format the information is returned in, error conditions, or any rate limits. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core purpose and context. Every word earns its place, with no redundant information. It's appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no output schema), the description is incomplete. It lacks details on return values (no output schema), error handling, or behavioral traits (no annotations). While the purpose is clear, operational context is minimal, making it inadequate for confident agent use without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter fully documented. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., no examples of valid IDs or format). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific step' (verb+resource). It distinguishes from siblings like 'goalstory_read_steps' (plural) by focusing on a single step. However, it doesn't explicitly differentiate from 'goalstory_read_one_goal' or 'goalstory_read_one_story' in terms of resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to support focused discussion and story creation'), suggesting when this tool might be valuable. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'goalstory_read_steps' (for multiple steps) or 'goalstory_read_one_goal' (for goals). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional pagination' which hints at behavior for large datasets, but doesn't disclose critical traits like whether this is a read-only operation (implied by 'Get' but not explicit), authentication needs, rate limits, error handling, or what the 'overview' includes (e.g., summary fields vs. full details). For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get an overview of the user's goal journey') and adds necessary context ('with optional pagination to manage larger sets of goals'). Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose and hints at pagination behavior, but lacks details on authentication, error cases, return format (e.g., what fields are in the 'overview'), or how it differs from sibling tools. For a read operation with no structured safety hints, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('page' and 'limit') well-documented in the schema. The description adds value by contextualizing pagination ('to manage larger sets of goals'), but doesn't provide additional semantics beyond what the schema already states (e.g., default values, constraints). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get an overview of the user's goal journey' specifies the verb ('Get') and resource ('user's goal journey'). It distinguishes from siblings like 'goalstory_read_one_goal' (single goal) and 'goalstory_count_goals' (count only), but doesn't explicitly contrast with 'goalstory_read_stories' or 'goalstory_read_steps' which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'optional pagination to manage larger sets of goals,' suggesting this tool is for browsing multiple goals. However, it doesn't explicitly state when to use this vs. alternatives like 'goalstory_read_one_goal' for a specific goal or 'goalstory_count_goals' for just a count. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval/information tool, implying read-only behavior, but doesn't address potential behavioral aspects like authentication requirements, rate limits, response format, or whether this returns static content vs. dynamic data. The description is minimal on behavioral traits beyond the basic purpose.
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 perfectly concise with two clear sentences. The first states what the tool does, the second states when to use it. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple informational retrieval tool with 0 parameters and no output schema, the description is adequate but minimal. It explains what information will be retrieved and the usage context, but doesn't describe the return format or structure. For a tool with no structured output documentation, more detail about what 'information' means would be helpful.
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 0 parameters with 100% schema description coverage. The description doesn't need to explain any parameters, which is appropriate. It focuses instead on what information will be retrieved. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve information about Goal Story's philosophy and the power of story-driven goal achievement.' It specifies both the action (retrieve information) and the subject (Goal Story's philosophy/approach). However, it doesn't explicitly differentiate from sibling tools like 'goalstory_get_story_context' which might also retrieve contextual information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Use this to help users understand the unique approach of Goal Storying.' This suggests the tool is for educational/contextual purposes rather than operational tasks. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get') but does not mention potential side effects, authentication needs, rate limits, or return format. For a tool with zero annotation coverage, this is a significant gap, as it leaves the agent guessing about behavioral traits beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a brief usage note. Every sentence earns its place by adding value: the first defines the tool, and the second provides context. There is zero waste, making it appropriately sized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but lacks details on behavioral aspects. It covers the purpose and usage context but does not address return values or potential constraints. For a simple read tool, this is adequate but has clear gaps in transparency.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, which is appropriate. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs without requiring additional explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the total number of goals in the user's journey.' It specifies the verb ('Get') and resource ('total number of goals'), but does not explicitly differentiate it from sibling tools like 'goalstory_read_goals' (which likely lists goals rather than counting them). The description is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Useful for tracking overall progress and goal management patterns.' This suggests when to use the tool (for progress tracking) but does not explicitly state when not to use it or name alternatives (e.g., 'goalstory_read_goals' for detailed goal lists). It offers some context but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details about behavioral traits: it doesn't mention whether this is a read-only operation (implied by 'identify' but not explicit), what permissions are required, how it determines 'current focus' (e.g., from user session or last interaction), or potential rate limits. For a tool with zero annotation coverage, this is a significant gap in 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 a single, well-structured sentence that efficiently conveys the tool's purpose and usage context. It's front-loaded with the core function ('Identify which goal and step...') and follows with the rationale ('to maintain context...'). Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 0 parameters) and the absence of annotations and output schema, the description is minimally adequate. It explains what the tool does but lacks details about behavioral aspects (e.g., how 'current focus' is determined) and output format. For a tool with no structured data to rely on, the description should provide more context to be fully 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?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it naturally meets the baseline. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Identify which goal and step the user is currently focused on.' It specifies the verb ('identify') and resource ('goal and step'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'goalstory_read_one_goal' or 'goalstory_read_one_step', which might retrieve specific goals/steps rather than the current focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'to maintain context in discussions and story creation.' This suggests it should be used when the agent needs to understand the user's current focus for conversational or creative tasks. However, it doesn't explicitly state when to use this tool versus alternatives like 'goalstory_read_goals' (which lists all goals) or 'goalstory_get_story_context' (which might provide broader context). No explicit exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a list with pagination and notes the timezone handling (UTC storage, requiring conversion), adding useful behavioral context. However, it doesn't cover other aspects like error conditions, authentication needs, or rate limits, leaving gaps for a read operation.
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 front-loaded with the core purpose in the first sentence, followed by an important note. Both sentences earn their place by providing essential information without redundancy. It could be slightly more structured but remains efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers the purpose, pagination, and timezone detail, but lacks information on return format, error handling, or authentication. For a read tool with two parameters, it's adequate but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (page and limit). The description adds no additional meaning beyond what the schema provides, such as default values or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('scheduled story generation configurations for the user'), making the purpose evident. It distinguishes from siblings like goalstory_read_stories by specifying 'scheduled' configurations, though it doesn't explicitly contrast with all read siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving scheduled configurations, but provides no explicit guidance on when to use this tool versus alternatives like goalstory_read_stories or goalstory_read_one_story. It mentions optional pagination, which hints at context for large datasets, but lacks when-not or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reads user data but does not disclose behavioral traits such as authentication requirements, rate limits, data freshness, or error handling. For a read operation with zero annotation coverage, this is a significant gap in 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 a single, well-structured sentence that efficiently conveys the tool's purpose, content, and intended use. It is front-loaded with the core action and resource, followed by details and purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read operation with no parameters) and lack of annotations and output schema, the description provides adequate purpose and usage context but is incomplete. It does not cover behavioral aspects like response format, data scope, or error conditions, which are important for a tool that fetches user data.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('user's profile data') with specific content details ('preferences, belief systems, and past goal history') and purpose ('to enable personalized goal storying and context-aware discussions'). It distinguishes from siblings like 'goalstory_update_self_user' (update vs. read) and 'goalstory_read_goals' (user data vs. goals). However, it doesn't explicitly contrast with all siblings, such as 'goalstory_read_current_focus' which might also provide user context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for personalization and context-aware discussions, suggesting it should be used when user profile data is needed. However, it lacks explicit guidance on when to use this tool versus alternatives like 'goalstory_read_current_focus' or 'goalstory_about', and does not specify prerequisites or exclusions. The context is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses the ordering mechanism ('ordered by their 'order_ts' timestamp in ascending order'), sequencing logic ('earliest timestamp is step 1'), and system-maintained ordering. However, it doesn't mention potential errors, authentication needs, or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by important ordering details. Every sentence earns its place by providing critical information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by explaining the ordering behavior and resource scope. However, it lacks details on error conditions, response format, or authentication requirements, which would be helpful for a read operation with pagination parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (goal_id, page, limit). The description adds no additional parameter semantics beyond what the schema provides, such as explaining pagination behavior or format details. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Access the action plan') and resource ('for a specific goal, showing all steps in the journey toward achievement'), distinguishing it from siblings like goalstory_read_one_step (single step) and goalstory_read_goals (goals list). It precisely communicates what the tool does without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it retrieves steps for a goal, but does not explicitly state when to use this tool versus alternatives like goalstory_read_one_step or goalstory_read_goals. It provides clear operational context but lacks explicit comparative guidance with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a destructive operation ('permanently removed' from input schema, 'Remove' in description) and adds valuable context about the scope of deletion ('all its associated steps and stories'). However, it doesn't mention potential side effects like error handling, permissions needed, or what happens if the goal doesn't exist.
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 just two sentences that are front-loaded with the core action and scope. Every word earns its place: the first sentence defines the operation, and the second provides critical usage guidance without any redundancy or fluff.
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 this is a destructive mutation tool with no annotations and no output schema, the description does well by clearly stating the destructive nature and scope. However, it could be more complete by mentioning what happens on success/failure or if there are any prerequisites. The high schema coverage helps compensate, but for a tool that permanently removes data, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter well-documented as 'Unique identifier of the goal to be permanently removed.' The description doesn't add any additional parameter information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
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 specific action ('Remove'), the target resource ('a goal and all its associated steps and stories'), and the scope ('from the user's journey'). It distinguishes itself from sibling tools like 'goalstory_destroy_step' and 'goalstory_destroy_scheduled_story' by specifying it removes the entire goal hierarchy, not just individual components.
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 provides usage guidance with 'Use with confirmation to prevent accidental deletion,' indicating when to use it (with user confirmation) and implying when not to use it (without confirmation). This distinguishes it from read-only siblings like 'goalstory_read_goals' and update tools like 'goalstory_update_goal,' which are safer operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behavioral traits: it's a mutation tool (implied by 'reorder'), specifies how ordering works (based on 'order_ts' timestamps), and details the system's response (assigns new timestamps based on array order). It also includes an 'IMPORTANT' note about the ordering mechanism, adding valuable context beyond basic functionality.
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 front-loaded with the core purpose in the first sentence, followed by important behavioral details in a structured manner. Every sentence adds value (e.g., explaining the ordering mechanism and system behavior), with no wasted words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with specific ordering logic), no annotations, and no output schema, the description does a strong job covering key aspects: purpose, usage, behavioral transparency, and parameter semantics. However, it lacks details on error conditions or response format, which could be useful for completeness, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameter well. The description adds meaningful context by explaining the semantic impact of the parameter ('the first ID becomes step 1, the second step 2, etc.') and reinforces the requirement for a full set of step IDs, which complements the schema without redundancy, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('reorder steps in a goal'), the resource ('steps'), and distinguishes it from siblings by explaining it reorganizes without deletion (unlike destroy_step). It explicitly mentions prioritizing or reorganizing workflow, making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to prioritize steps or reorganize the workflow without deleting and recreating steps'), which helps differentiate it from alternatives like destroy_step or update_step. However, it does not explicitly state when not to use it or name specific sibling tools as alternatives, keeping it from a perfect score.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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