Skip to main content
Glama
cdmx-in
by cdmx-in

get_goodday_smart_query

Query Goodday project management data using natural language to retrieve information about projects, tasks, and users without modifying any data.

Instructions

Natural language interface for common project management queries.

Args: query: Natural language query (e.g., "show me all tasks assigned to John", "what projects do I have")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes

Implementation Reference

  • The handler function for the 'get_goodday_smart_query' tool. It processes natural language queries by matching patterns to call other Goodday tools like get_projects, get_users, get_user_assigned_tasks, etc.
    @mcp.tool()
    async def get_goodday_smart_query(query: str) -> str:
        """Natural language interface for common project management queries.
    
        Args:
            query: Natural language query (e.g., "show me all tasks assigned to John", "what projects do I have")
        """
        query_lower = query.lower().strip()
        
        # Parse common query patterns
        if "projects" in query_lower and ("my" in query_lower or "i have" in query_lower):
            return await get_projects()
        elif "users" in query_lower or "team members" in query_lower:
            return await get_users()
        elif "assigned to" in query_lower:
            # Extract user name from query
            user_match = re.search(r"assigned to (\w+)", query_lower)
            if user_match:
                user_name = user_match.group(1)
                user = await find_user_by_name_or_email(user_name)
                if user:
                    return await get_user_assigned_tasks(user.get("id"))
                else:
                    return f"User '{user_name}' not found."
            else:
                return "Please specify a user name for assigned tasks query."
        elif "action required" in query_lower:
            # Extract user name from query
            user_match = re.search(r"action required (?:for|by) (\w+)", query_lower)
            if user_match:
                user_name = user_match.group(1)
                user = await find_user_by_name_or_email(user_name)
                if user:
                    return await get_user_action_required_tasks(user.get("id"))
                else:
                    return f"User '{user_name}' not found."
            else:
                return "Please specify a user name for action required tasks query."
        else:
            return f"Query not recognized. Try queries like:\n- 'show me all projects'\n- 'show me all users'\n- 'show tasks assigned to [user]'\n- 'show action required tasks for [user]'"
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.

Install Server

Other Tools

Latest Blog Posts

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