goodday-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between get_task and get_task_details, and between get_project_tasks and get_goodday_sprint_tasks, which could cause confusion. Additionally, get_goodday_smart_query overlaps with several search and retrieval tools, though its natural language interface is a differentiating factor.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_project, get_task, update_task_status) with minor deviations like get_goodday_smart_query and search_goodday_tasks that include 'goodday' inconsistently. Overall, the pattern is clear and readable, with only slight inconsistencies.
Tool Count3/5
With 21 tools, the count is on the higher side for a project management server, bordering on heavy. While it covers many aspects, some tools might be redundant or could be consolidated, making it feel slightly bloated but still within a reasonable range for the domain.
Completeness4/5
The toolset provides comprehensive coverage for project and task management, including CRUD operations for projects, tasks, and comments, as well as retrieval for users, documents, and sprints. Minor gaps include lack of update/delete for projects and tasks, and no direct document creation tool, but core workflows are well-supported.
Average 3.1/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 the tool adds a comment (implying a write/mutation operation) but doesn't mention required permissions, whether comments are editable/deletable, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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 and front-loaded with the core purpose in the first sentence. The parameter explanations are brief but relevant. There's minimal waste, though the structure could be slightly improved by integrating parameter details more seamlessly.
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, no output schema, and 0% schema description coverage, the description is incomplete. It lacks behavioral context (permissions, side effects), output expectations, and sufficient parameter details, making it inadequate for reliable 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 0%, so the description must compensate. It lists all three parameters with brief explanations, adding meaning beyond the bare schema. However, it doesn't provide format details (e.g., ID formats, message length limits) or deeper context, leaving gaps in parameter understanding.
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 ('Add a comment') and resource ('to a task'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'update_task_status' or 'get_task_messages' that might also involve task interactions, so it misses full 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for adding comments, or how this differs from other task-related tools like 'update_task_status' or 'get_task_messages' in the sibling list.
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 but offers minimal behavioral insight. It states it 'retrieves' content, implying a read-only operation, but doesn't cover permissions, rate limits, error handling, or output format (e.g., text, binary, structured data). This is inadequate for a tool with no annotation coverage.
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 a brief parameter explanation. It avoids redundancy and is appropriately sized for a simple tool, though the 'Args:' section could be integrated more smoothly.
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, 0% schema coverage, and no output schema, the description is insufficient. It doesn't explain what 'content' means (e.g., full text, attachments), potential side effects, or how results are returned, making it hard for an agent to use correctly without trial and error.
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 description adds basic meaning by explaining that 'document_id' identifies the document to retrieve, which is helpful since schema description coverage is 0%. However, it doesn't specify the ID format (e.g., numeric, UUID) or where to find it, leaving gaps despite the single parameter.
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 ('Get') and resource ('content of a specific document'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'search_project_documents' or 'get_task_details', which might also retrieve document-related content in different contexts.
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. With siblings like 'search_project_documents' and 'get_task_details', it's unclear if this is for raw document content, metadata, or specific contexts, leaving the agent to guess based on tool names 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving task details but doesn't cover aspects like authentication needs, rate limits, error handling, or response format. This is inadequate for a tool with zero annotation coverage.
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 a concise parameter explanation. There is no wasted text, and the structure is clear and 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 the complexity of task management tools, no annotations, no output schema, and low schema coverage, the description is insufficient. It lacks details on return values, error conditions, and how it differs from similar tools, making it incomplete 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 0%, but the description adds minimal semantics by specifying 'task_id' as 'The ID of the task to retrieve'. This clarifies the parameter's purpose slightly beyond the schema's title 'Task Id', though it doesn't detail format or constraints. Baseline 3 is appropriate as it compensates somewhat for low 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 'Get' and resource 'details of a specific task', making the purpose evident. However, it doesn't differentiate from sibling tools like 'get_task_details' or 'get_project_tasks', which could cause confusion about scope or specificity.
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?
No guidance is provided on when to use this tool versus alternatives such as 'get_task_details' or 'get_project_tasks'. The description only states what it does, leaving the agent to infer usage context from tool names 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 only states what the tool does without mentioning permissions, rate limits, return format, or pagination. For a read operation with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose in the first sentence. The additional 'Args' section is brief and relevant, though it could be integrated more seamlessly. Overall, it avoids unnecessary verbosity.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'action required tasks' entail, how results are returned, or any behavioral traits. For a tool with one parameter but no structured support, more context is needed to be fully helpful.
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 description adds minimal semantics for the 'user_id' parameter by stating it's 'The ID of the user', which is slightly more informative than the schema's 'User Id' title. With 0% schema description coverage, this provides some value, but it does not fully compensate for the lack of detailed parameter documentation.
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 'Get' and the resource 'action required tasks for a specific user', making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_user_assigned_tasks' or 'get_task', leaving some ambiguity about what distinguishes 'action required' tasks from other task types.
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 does not mention sibling tools like 'get_user_assigned_tasks' or 'get_task', nor does it specify prerequisites or exclusions, leaving the agent to infer usage context.
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 this is an update operation (implying mutation) but doesn't describe what happens during status updates: whether this triggers notifications, changes task visibility, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 and front-loaded with the core purpose in the first sentence. The parameter explanations are concise and directly relevant. While efficient, the structure could be slightly improved by grouping required vs optional parameters more clearly, but overall it's well-organized with minimal 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?
Given this is a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what happens after the update, what the return value might be, error conditions, or behavioral implications. For a tool that modifies task state, this leaves too many contextual gaps for reliable agent usage.
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 0%, so the description must compensate. It provides basic semantic meaning for all 4 parameters beyond their titles, explaining what each represents. However, it doesn't provide format details (what valid status_id values are, how task_id/user_id are formatted), constraints, or examples. The description adds value but doesn't fully compensate for the complete lack of schema descriptions.
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 ('status of a task'), making the purpose immediately understandable. It distinguishes from siblings like 'add_task_comment' or 'create_task' by focusing specifically on status modification rather than creation or commenting. However, it doesn't explicitly differentiate from potential status-related alternatives that might not exist in the sibling list.
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. While it's clear this updates task status, there's no mention of prerequisites, when status updates are appropriate versus using 'add_task_comment', or any context about status transitions. The agent must infer usage from the tool name alone without explicit guidance.
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 'Create a new project,' implying a write/mutation operation, but doesn't cover critical aspects like required permissions, whether the creation is irreversible, rate limits, or what happens on success/failure (e.g., returns a project ID). This is inadequate for a mutation tool with zero annotation coverage.
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 structured with a clear purpose statement followed by parameter details, but it's somewhat verbose with repetitive formatting. Every sentence in the 'Args' section adds value, but the overall text could be more streamlined (e.g., combining related parameters). It's front-loaded with the core function, but not optimally concise.
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 (9 parameters, mutation operation, no annotations, no output schema), the description is partially complete. It covers parameter semantics well but lacks behavioral context (e.g., permissions, side effects) and output details. For a creation tool, this leaves significant gaps, making it minimally adequate but with clear room for improvement.
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 description includes an 'Args' section that documents all 9 parameters with brief explanations, such as 'Project name' for 'name' and 'Project template ID (found in Organization settings → Project templates)' for 'project_template_id'. Since schema description coverage is 0%, this fully compensates by adding meaning beyond the bare schema, though some explanations could be more detailed (e.g., format hints beyond dates).
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: 'Create a new project in Goodday.' This is a specific verb ('Create') and resource ('project in Goodday'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_project' or 'get_projects', which are read operations, 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. It doesn't mention prerequisites (e.g., user permissions), when not to use it, or refer to sibling tools like 'get_project' for checking existing projects. This lack of context leaves 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves user details, implying a read-only operation, but does not disclose any behavioral traits such as authentication requirements, rate limits, error handling, or what specific details are returned. This is a significant gap for a tool with no annotation coverage.
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 and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args' section for parameters. There is no wasted text, and the structure enhances readability. However, it could be slightly more concise by integrating the parameter explanation into the main description.
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 (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It does not explain what details are returned (e.g., user name, email, role), potential errors, or how it differs from sibling tools like 'get_users'. For a tool with no structured data support, more contextual information is needed.
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 description adds meaningful context for the single parameter: 'user_id: The ID of the user to retrieve.' With schema description coverage at 0% (the schema only provides a title 'User Id' and type 'string'), the description compensates by explaining the parameter's purpose. Since there is only one parameter, the baseline is high, and the description adequately clarifies its semantics.
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 details of a specific user.' It specifies the verb ('Get') and resource ('user'), but does not distinguish it from sibling tools like 'get_users' (which likely retrieves multiple users) or 'get_project_users' (which might retrieve users within a project context). The purpose 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 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 does not mention sibling tools such as 'get_users' (for listing users) or 'get_project_users' (for users in a project), nor does it specify prerequisites or exclusions. Usage is implied only by the tool name and description, with no explicit context.
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 tool is a 'natural language interface' but doesn't describe what it returns (e.g., structured data, summaries), any limitations (e.g., query complexity, supported intents), or performance aspects. This leaves significant gaps for a tool that likely processes queries in a non-trivial way.
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 a clear front-loaded purpose statement and a brief parameter explanation. The two-sentence structure is efficient, though the examples could be integrated more smoothly. It avoids unnecessary repetition, earning its place with minimal 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?
Given the tool's complexity (natural language processing), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on return values, error handling, query limitations, and how it differs from structured search siblings, making it inadequate for confident agent use without additional 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 0%, so the description must compensate. It adds meaning by explaining the 'query' parameter as a 'natural language query' and provides examples (e.g., 'show me all tasks assigned to John'), which clarifies the expected input format beyond the schema's basic string type. However, it doesn't detail constraints like length, supported languages, or query types, leaving some ambiguity.
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 as a 'natural language interface for common project management queries,' which is specific (verb+resource) and distinguishes it from most sibling tools that are structured API calls. However, it doesn't explicitly differentiate from other query/search siblings like 'search_goodday_tasks' or 'search_project_documents' beyond the natural language aspect.
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 through the phrase 'common project management queries' and provides examples, suggesting it's for general queries rather than specific structured operations. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_goodday_tasks' or when not to use it, leaving some ambiguity.
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 generating a 'comprehensive' summary but doesn't specify output format (e.g., structured data vs. text report), data sources, permissions required, rate limits, or whether it's a read-only operation. This is inadequate for a tool that presumably queries and aggregates data.
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 efficiently structured: a clear purpose statement followed by an 'Args' section with parameter explanations. Every sentence adds value, with no redundant information. The two-sentence format is appropriately front-loaded with the core functionality.
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 of generating a 'comprehensive' summary with metrics, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what 'comprehensive' includes (e.g., specific metrics like velocity or burndown), output format, or behavioral characteristics like error handling or data freshness.
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 0%, so the description must compensate. It provides clear examples for both parameters ('project_name' with 'ASTRA', 'sprint_name' with 'Sprint 233' or '233'), adding practical meaning beyond the bare schema. However, it doesn't explain constraints like valid project/sprint names or format requirements.
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 a comprehensive sprint summary with task details, status distribution, and key metrics.' This specifies the verb ('generate'), resource ('sprint summary'), and scope ('comprehensive'), though it doesn't explicitly differentiate from sibling tools like 'get_goodday_sprint_tasks' or 'get_goodday_smart_query'.
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 sibling tools like 'get_goodday_sprint_tasks' (which might list tasks without summary metrics) or 'get_goodday_smart_query' (which could potentially generate similar reports), leaving 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It describes a read operation ('Get tasks'), which implies non-destructive behavior, but doesn't address other important traits: authentication requirements, rate limits, pagination, error handling, or return format. The description adds minimal behavioral context beyond the basic operation, leaving significant gaps for the agent.
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 and well-structured: a clear purpose statement followed by an 'Args:' section with parameter details. Every sentence adds value, with no redundant or vague phrasing. It could be slightly more front-loaded by integrating parameter hints into the main description, but overall it's efficient and readable.
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 moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral details (e.g., authentication, pagination) and output information. Without annotations or output schema, the agent is left guessing about the return format and operational constraints, making this description minimally viable but with clear gaps.
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 0%, so the description must compensate. It provides clear semantics for all three parameters: 'project_name' (name of main project with example 'ASTRA'), 'sprint_name' (name/number with examples 'Sprint 233', '233'), and 'include_closed' (whether to include closed tasks with default True). This adds meaningful context beyond the bare schema, though it doesn't cover edge cases or validation rules.
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 tasks from a specific sprint by project name and sprint name/number.' This specifies the verb ('Get'), resource ('tasks'), and key constraints ('specific sprint', 'by project name and sprint name/number'). However, it doesn't explicitly differentiate from sibling tools like 'get_project_tasks' or 'get_goodday_smart_query', which reduces it from a perfect 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. It doesn't mention sibling tools like 'get_project_tasks' (for tasks in a project generally) or 'get_goodday_sprint_summary' (for sprint metadata), leaving the agent to infer usage context. The only implied usage is retrieving sprint-specific tasks, but no explicit when/when-not rules or alternatives are stated.
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 project details, implying a read-only operation, but does not specify aspects like authentication requirements, rate limits, error handling, or what 'details' include (e.g., fields returned). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a concise 'Args' section. There is no wasted text, and the structure is easy to parse. It could be slightly more efficient by integrating the parameter explanation into the main description, but it remains highly concise.
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 explains the purpose and parameter, but lacks details on behavior, output format, or usage context. For a simple read operation, this is acceptable but leaves gaps that could hinder an agent's understanding without further context.
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 description adds meaningful context for the single parameter: 'project_id: The ID of the project to retrieve.' Since schema description coverage is 0% (the schema only provides a title 'Project Id' with no description), this compensates well by explaining the parameter's purpose. With 1 parameter and low schema coverage, the description effectively clarifies semantics.
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 details of a specific project.' It uses a specific verb ('Get') and resource ('project'), but does not explicitly differentiate from sibling tools like 'get_projects' (which likely lists multiple projects) or 'get_project_tasks' (which focuses on tasks within a project). The purpose is clear but lacks 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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_projects' for listing projects or 'get_project_tasks' for project-related tasks, nor does it specify prerequisites or exclusions. Usage is implied only by the tool name and description.
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 only describes two filtering parameters without mentioning important behavioral aspects like: whether this is a read-only operation, what format the list returns (pagination, sorting, fields included), authentication requirements, rate limits, or error conditions. The description is insufficient for a tool with no annotation coverage.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place by providing essential information. The two-sentence format with parameter documentation is appropriately sized for this 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?
Given the tool has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. While it covers parameter semantics well, it lacks crucial information about the tool's behavior, return format, authentication requirements, and error handling. For a tool that presumably returns a list of projects, more context about what to expect 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 description adds meaningful semantic context for both parameters that goes beyond the schema. While the schema only shows boolean parameters with titles 'Archived' and 'Root Only', the description explains what these actually mean: 'retrieve archived/closed projects' and 'return only root projects'. This provides crucial understanding of what these filters accomplish, compensating for the 0% schema description 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 'Get' and resource 'list of projects from Goodday', making the purpose understandable. It distinguishes from sibling 'get_project' (singular) by indicating it returns a list, but doesn't explicitly differentiate from other project-related tools like 'get_project_tasks' or 'get_project_users'.
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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention when you'd want a list of projects versus using other project-related tools like 'get_project' (singular) or 'search_goodday_tasks', nor does it provide any context about prerequisites or typical use cases.
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 retrieving tasks but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what happens when project_id is invalid. The boolean parameter explanations add some context but don't cover broader operational 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 appropriately sized with a clear purpose statement followed by parameter explanations. The Args section is well-structured, though the initial sentence could be slightly more specific (e.g., 'Retrieve tasks...'). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters and no output schema, the description covers the basics but lacks important context. It explains parameters well but doesn't describe return format, pagination, error handling, or relationship to sibling tools. Without annotations or output schema, more behavioral disclosure 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?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: project_id identifies the project, closed controls inclusion of completed tasks, and subfolders extends scope to nested folders. This adds meaningful semantics beyond the bare schema titles, though it doesn't specify format for project_id.
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 'Get' and resource 'tasks from a specific project', making the purpose immediately understandable. It distinguishes from siblings like 'get_task' (single task) and 'get_projects' (projects list), though it doesn't explicitly contrast with 'search_goodday_tasks' or 'get_user_assigned_tasks'.
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. With siblings like 'search_goodday_tasks', 'get_user_assigned_tasks', and 'get_task', there's no indication whether this is the primary task-listing method or when project-specific filtering is preferred over other filters.
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. While 'Get' implies a read operation, it doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, or whether this is a heavy API call. The description mentions what data is returned but not how it's structured or formatted.
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 a clear main sentence followed by parameter explanations. The Args section is well-structured, though the formatting could be slightly cleaner. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read tool with no annotations and no output schema, the description covers the purpose and parameters adequately but lacks behavioral context and usage guidance. It doesn't explain what 'comprehensive' means in practice or how the output is structured, leaving gaps for an AI agent.
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?
With 0% schema description coverage, the description adds significant value by explaining both parameters. It clarifies that 'task_short_id' uses a specific format (e.g., RAD-434) and that 'project_name' is case-insensitive and required. This compensates well for the schema's lack of descriptions.
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 'Get' and resource 'comprehensive task details', specifying what information is included (subtasks, custom fields, full metadata). It distinguishes from simpler sibling tools like 'get_task' by emphasizing comprehensiveness, though it doesn't explicitly contrast with all siblings like 'get_task_messages'.
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. With multiple sibling tools like 'get_task', 'get_project_tasks', and 'search_goodday_tasks', there's no indication of when this comprehensive details tool is preferred over simpler or broader alternatives.
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 this is a retrieval operation but doesn't mention important behavioral aspects: whether this requires authentication, rate limits, pagination behavior, error conditions, or what format the messages/comments are returned in. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 and front-loaded with the core purpose in the first sentence. The parameter documentation is cleanly separated with 'Args:' formatting. There's minimal waste, though the structure could be slightly improved by integrating parameter explanations more naturally rather than as a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 2 parameters and no output schema, the description covers the basic purpose and parameters adequately. However, it lacks important context about return format, error handling, authentication requirements, and relationship to sibling tools. Without annotations or output schema, the description should do more to explain what the agent can expect from this tool's behavior and results.
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?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'task_short_id' is described with an example format ('RAD-434'), and 'project_name' is explained as 'Optional project name for disambiguation.' This adds meaningful context beyond what the bare schema provides, though it doesn't elaborate on when disambiguation is needed or how the project name affects results.
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 ('all messages/comments for a specific task'), making the purpose immediately understandable. It distinguishes from siblings like 'get_task' or 'get_task_details' by focusing specifically on messages/comments rather than task metadata. However, it doesn't explicitly contrast with 'add_task_comment' which is the natural sibling for message operations.
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. With siblings like 'get_task_details' that might include messages, 'search_goodday_tasks' for broader queries, and 'add_task_comment' for creating messages, there's no indication of when this specific retrieval tool is preferred. The parameter documentation implies usage but doesn't provide contextual guidance.
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 tasks but doesn't describe return format (e.g., list structure, fields included), pagination, error handling, or authentication needs. The 'closed' parameter hint adds some context, but overall, behavioral traits are minimally covered.
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 and front-loaded, with the core purpose stated first and parameter details following in a clear 'Args:' section. Every sentence adds value, and there's no redundant information. It could be slightly more structured but remains 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 moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and parameters but lacks details on output format, error cases, and differentiation from siblings. Without annotations or output schema, it provides a minimum viable understanding but could be more complete for reliable agent use.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains 'user_id' as 'The ID of the user' and 'closed' as 'Set to true to retrieve all open and closed tasks,' clarifying default behavior and usage. This compensates well for the schema's lack of descriptions, though it doesn't detail parameter formats or constraints.
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 tasks assigned to a specific user.' This is a specific verb ('Get') and resource ('tasks assigned to a specific user'), making the function unambiguous. However, it doesn't explicitly differentiate from siblings like 'get_user_action_required_tasks' or 'search_goodday_tasks', which might also retrieve user-related tasks.
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 siblings like 'get_user_action_required_tasks' (which might filter by action required) or 'search_goodday_tasks' (which might allow broader searches), nor does it specify prerequisites or exclusions. Usage is implied by the name and description 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'vector similarity search' which provides some technical context, but doesn't describe what 'vector similarity' means in practice, how results are ranked, whether this is a read-only operation, what authentication is required, or any rate limits. The description is insufficient for a search tool with 5 parameters and no annotation coverage.
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 a clear opening sentence followed by a well-structured Args section. Each parameter explanation is concise and adds value. The structure helps the agent quickly understand the tool's purpose and parameters without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, no annotations, and no output schema, the description provides adequate parameter semantics but lacks important context about the search behavior, result format, and how it differs from sibling search tools. The absence of output schema means the description should ideally mention what the search returns, but it doesn't. The parameter explanations help, but behavioral context is incomplete.
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?
With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section. It clarifies that 'query' accepts natural language, 'limit' has default and maximum values, 'project_name' uses case-insensitive partial matching, 'user_name' filters for assigned tasks, and 'include_closed' controls completed task inclusion. This adds substantial value beyond the bare schema.
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 searches for tasks using vector similarity search with optional filters, which is a specific verb+resource combination. It distinguishes itself from other task-related tools like get_task or get_user_assigned_tasks by emphasizing vector similarity search capabilities. However, it doesn't explicitly differentiate from search_project_documents which also uses search functionality.
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 get_goodday_smart_query, get_user_assigned_tasks, or search_project_documents. There's no mention of prerequisites, performance considerations, or specific scenarios where vector similarity search is preferred over other search methods available in the 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 mentions that searches are 'case-insensitive' and 'partial match' for document_name, which adds useful context beyond the schema. However, it doesn't cover critical behaviors like pagination, rate limits, authentication needs, error conditions, or what the output looks like (e.g., list format). For a search 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section with concise explanations for each parameter. There's no wasted text, and the information is organized for quick scanning. It could be slightly more concise by integrating the parameter details into the main flow, but it's efficient overall.
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 (a search tool with 3 parameters), no annotations, and no output schema, the description is partially complete. It covers parameter semantics well but lacks details on behavioral aspects like output format, error handling, or performance characteristics. For a tool with no structured output or annotation support, the description should do more to compensate, but it meets a minimum viable level by explaining the parameters and basic search behavior.
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 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'project_name' is required and case-insensitive, 'document_name' is optional with case-insensitive partial matching, and 'include_content' controls whether full content is returned. This goes beyond the schema's basic type definitions, providing practical usage details that help the agent invoke the tool correctly.
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: 'Search for documents in a specific project.' It specifies the verb ('search'), resource ('documents'), and scope ('in a specific project'), which is clear and specific. However, it doesn't explicitly differentiate from sibling tools like 'get_document_content' or 'search_goodday_tasks', which would require a 5.
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. There's no mention of sibling tools like 'get_document_content' (for retrieving content of a specific document) or 'search_goodday_tasks' (for searching tasks instead of documents), nor any context about prerequisites or exclusions. The only implied usage is searching documents within projects, but this is basic and lacks explicit alternatives.
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. While 'Create' implies a write/mutation operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what happens on success (e.g., returns task ID). It also doesn't clarify if creating subtasks via parent_task_id has special behavior. This leaves significant 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 appropriately sized but not optimally structured. The opening sentence is clear, but the parameter documentation uses inconsistent formatting and mixes explanations with format notes. Some redundancy exists (e.g., 'Task' repeated in many parameter descriptions). While all information is valuable given the poor schema coverage, the presentation could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 13 parameters, no annotations, and no output schema, the description provides good parameter semantics but lacks critical behavioral context. The agent knows what each parameter means but not what authentication is needed, what happens on success/failure, or how this tool relates to others in the system. The parameter documentation is strong, but other aspects are underdeveloped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (titles only show parameter names), the description provides crucial semantic information for all 13 parameters. It explains what each parameter represents (e.g., 'Task project ID', 'Task title', 'Task created by user ID'), clarifies data formats (YYYY-MM-DD for dates), defines numeric ranges (priority 1-10 with special values 50 and 100), and explains relationships (parent_task_id creates a subtask). This fully compensates for the schema's lack of descriptions.
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 'Create a new task in Goodday' which is a specific verb+resource combination. It distinguishes this from sibling tools like 'update_task_status' or 'get_task' by focusing on creation rather than modification or retrieval. However, it doesn't explicitly differentiate from 'create_project' which creates a different 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 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. There's no mention of prerequisites (like needing valid project/user IDs), when not to use it, or how it relates to sibling tools like 'create_project' or 'update_task_status'. The agent must infer usage from the tool name and parameter list 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it 'gets' data (implied read-only) but doesn't cover pagination, sorting, filtering, rate limits, authentication needs, or what 'organization users' entails (e.g., active vs. all).
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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description is minimally adequate but lacks depth. It doesn't explain return format (e.g., list structure, fields) or behavioral context, leaving gaps for an agent to infer usage.
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 coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here, earning a baseline high score for simplicity.
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 ('Get') and resource ('list of organization users'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_user' (singular) or 'get_project_users', which could cause confusion about scope.
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 'get_user' (for a single user) or 'get_project_users' (for users in a specific project). There's no mention of prerequisites, context, 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 only states what the tool does ('Get users') without mentioning any behavioral traits such as whether it's read-only (implied by 'Get' but not explicit), what permissions are required, how results are returned (e.g., list format, pagination), or error handling. 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 appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by a brief 'Args' section for parameters. There is no wasted text, and every sentence earns its place by providing essential information efficiently. It's structured for quick comprehension without unnecessary details.
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 nested objects, no output schema) and lack of annotations, the description is minimally complete. It covers the basic purpose and parameter semantics but lacks behavioral details (e.g., return format, error cases) and usage guidelines vs. siblings. For a simple read operation, this might be adequate, but it doesn't fully compensate for the missing annotations and output schema, leaving room for improvement.
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 description adds meaningful context for the single parameter: 'project_id: The ID of the project.' Since schema description coverage is 0% (the schema only provides a title 'Project Id' and type 'string'), this description compensates by explaining what the parameter represents. However, it doesn't specify format (e.g., numeric, UUID) or where to find the ID, leaving minor gaps. With 0% coverage and 1 parameter, a baseline of 4 is appropriate as it adds value beyond the schema.
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 users associated with a specific project.' It specifies the verb ('Get') and resource ('users'), and distinguishes it from sibling tools like 'get_users' (which presumably gets all users) by focusing on project-specific users. However, it doesn't explicitly differentiate from 'get_user' (which gets a single user) or 'get_user_assigned_tasks' (which focuses on tasks), so it's not a perfect 5.
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 stating it's for getting users 'associated with a specific project,' suggesting it should be used when you need project-related user data. However, it doesn't explicitly say when to use this vs. alternatives like 'get_users' (for all users) or 'get_user' (for a single user), nor does it mention any exclusions or prerequisites. This leaves some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![goodday-mcp MCP server](https://glama.ai/mcp/servers/cdmx-in/goodday-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cdmx-in/goodday-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/cdmx-in/goodday-mcp'

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