System Task MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: team lists vs. team load, project overview vs. report vs. risks, task search vs. task get, and create for self vs. create for others. Descriptions explicitly cross-reference to avoid overlap, so an agent can reliably pick the right tool.
Naming Consistency4/5
All tools share the 'systemtask_' prefix and use snake_case, with most following a 'resource_action' pattern (e.g., task_get, task_update, demand_create). Minor deviations like 'day_brief', 'project_report', 'project_risks', and 'whoami' break the pattern slightly but remain readable and identifiable.
Tool Count5/5
With 15 tools, the set is well-scoped for its domain. Each tool serves a clear purpose—from project overviews and team load to full task lifecycle operations—without redundancy. The count sits at the upper end of the ideal range but feels justified.
Completeness4/5
The surface covers project monitoring, team awareness, personal planning, and a full task lifecycle (search, get, create, update, assign, move, comment). The lack of delete and subtask editing is intentional and documented, so agents can work around it, but these are still minor gaps.
Average 4.3/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Beyond that, the description adds behavioral logic: it includes late tasks, tasks without date/responsible, prioritizes the oldest tasks, and highlights the intersection of missing date AND responsible as the 'task nobody will do'. This gives the agent insight into selection criteria and prioritization.
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 and front-loaded with the key question. It efficiently conveys the risk categories and the special meaning of the intersection. Minor redundancy exists in repeating 'sem data e sem responsável' but each sentence contributes meaningful information.
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?
With no output schema, the description should clarify the return format. It explains the filtering logic and which tasks are considered risky, but does not state whether it returns a list of tasks, a summary, or what fields are included. This is a moderate gap given the absence of an output schema, but the tool's intent is reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (project and sample), so the schema already fully documents their meaning. The description does not add parameter-specific semantics beyond implying that 'sample' relates to the oldest tasks mentioned, but this is not a significant addition over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as surfacing project risks: late tasks, tasks without date, and tasks without assignee. It specifies the resource (project) and the specific risk dimensions, differentiating it from general task listing or report tools by focusing on problematic task categories.
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 clear context about what the tool surfaces but does not explicitly mention when to use it instead of sibling tools like systemtask_project_report or systemtask_tasks_search. The use case is implied (when you need to identify project risks), but no exclusions or alternative recommendations are given.
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?
Annotations already declare read-only and non-destructive behavior, so the description does not need to repeat that. It adds useful context beyond annotations, such as the 92-day maximum period and clarifies the inflow-vs-completion metric, though it does not describe output structure or pagination.
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 entire description is a single, dense sentence that front-loads the purpose and lists the metrics efficiently. The parenthetical flourish about the project 'sinking' is stylistic but not wasteful, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report with no output schema, the description covers the main returned dimensions and the date-range limit. It lacks explicit return format or response shape, but the listed metrics provide enough context for selection and 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 coverage is 100% and each parameter has a description, providing a solid baseline. The description adds a period constraint (92 days) and reinforces the project parameter behavior, but it does not materially change understanding beyond what the schema already conveys.
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 defines a project status dashboard and enumerates specific metrics (totals, completed, open, late, board distribution, priority distribution, inflow vs. outflow). It distinguishes itself from sibling tools like project_risks and projects_list by its summary-report scope, though it lacks a direct imperative verb.
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 phrase 'Como um projeto está' establishes the context for when to use this tool: to obtain a project status overview. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to choose it over more specific 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?
The annotations only indicate that the tool is mutating and non-destructive. The description adds valuable behavioral context: it explains that doneWhen must be verifiable by another person, gives examples of acceptable criteria, and states that the agent should ask the user rather than invent criteria. It also clarifies when subtasks are appropriate. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence serves a purpose: the first paragraph states the core function, the second gives outcome-oriented guidance, the third details the doneWhen requirement and how to handle vague requests, and the fourth clarifies subtask usage. It is well-structured and front-loaded, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description provides substantial context about what a 'demand' is and how to structure key fields. It does not mention every parameter, but the schema descriptions cover those. The instruction to ask the user when details are insufficient is a key completeness element that supports correct invocation.
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 schema already covers 90% of parameters with descriptions, so a baseline of 3 is appropriate. The description adds extra semantic value by elaborating on 'doneWhen' with concrete examples ('um número, um arquivo, um link') and by defining when 'subtasks' should be used. It also frames 'objective' and 'deliverable' as outcome-focused rather than method-focused, which enhances the schema's meaning.
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 and resource: 'Registra uma DEMANDA num projeto' (registers a demand in a project). It distinguishes this as a creation tool, but does not explicitly differentiate it from the sibling tool systemtask_task_create, so it falls just short of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage guidance: it instructs the user to say what should exist, not how, and explicitly says to ask the user if the request is too vague to define a doneWhen criterion. However, it does not compare this tool with alternatives like task_create, which would help the agent choose between them.
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?
The description goes beyond annotations by explaining that the comment 'fica registrado para quem abrir depois' (is recorded for later viewers) and that '@usuario' triggers a notification. This adds behavioral context about persistence and side effects that the annotations (readOnlyHint=false, destructiveHint=false) do not express. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two sentences, front-loaded with the action verb and resource. The second sentence adds useful guidance about @mentions, and the metaphor about returning results to the team is contextually rich though slightly non-essential. Overall it is efficient and well-structured, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the action, purpose, persistence, and notification behavior. The annotations already cover safety, so the description is sufficiently complete for an agent to decide when and how to invoke it. It could mention return values but that isn't required given the absence of an output schema.
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 already has 100% coverage: both parameters ('task' with an integer id, 'text' with length constraints and mention capability) are described in the schema. The description only reiterates the '@usuario' mention feature, adding no new semantic value beyond the schema. Hence the baseline 3 for high schema coverage.
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 opens with 'Escreve um comentário na tarefa' — a specific verb ('Escreve') and resource ('tarefa'), clearly distinguishing this from sibling tools like task_create or task_update. It also explains the broader purpose: it's how the agent returns results to the team, which clarifies why this tool exists.
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 phrase 'é como o agente devolve resultado para a equipe' provides a clear usage context: use this to communicate results back to the team. It also mentions that '@usuario' notifies a person, which is a practical guideline. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.
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?
Despite annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds crucial non-obvious behavior: moving a recurrent task moves the whole series by default, and moving only the instance causes it to revert to the old project. This goes beyond annotation hints. It does not discuss permissions or other side effects, but the disclosure is strong.
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, with the core action in the first sentence and the critical recurrent caveat in the second. No filler or redundancy; front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation, the description covers the primary function and the most important edge case. It lacks explicit return-value or error details, but no output schema exists and the tool's scope is narrow, making this adequate. Combined with 100% schema coverage and annotations, an agent can invoke 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?
The input schema covers all three parameters with complete descriptions, including onlyThis's purpose. The description essentially recaps the onlyThis semantics in prose without adding new parameter-level information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Muda a tarefa de projeto', clearly identifying the action (move) and resource (task project). It distinguishes itself from siblings like task_assign or task_update by focusing specifically on changing project and adding recurrence behavior, which no other tool mentions.
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?
It provides clear context for when to use the tool, especially the default behavior for recurrent tasks and the onlyThis parameter to override it. However, it does not explicitly state alternatives or exclusions relative to sibling tools like task_update.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict these. It adds modest context by clarifying the return type ('não linhas' vs numbers) and that the tool lists tasks for later editing, but it does not disclose pagination, default limits, or any additional behavioral nuances beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose in the first sentence and a clear usage alternative in the second. Every word earns its place with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-with-filters tool, the description plus the comprehensive schema annotations cover the essential information: what it lists, how to filter, and when to prefer an alternative. The absence of an output schema is mitigated by the obvious 'lines' vs 'numbers' contrast, though it could have briefly mentioned default limits or that results are flat rows.
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% parameter description coverage, so the schema already documents each parameter. The description's grouping of filters ('projeto, responsável, situação e período') is a helpful summary but does not add new meaning beyond what the schema provides, meriting the baseline score 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 opens with 'Lista tarefas filtrando por projeto, responsável, situação e período' — a specific verb ('lista') plus resource ('tarefas') and the main filtering dimensions. It also distinguishes itself from sibling tool systemtask_project_report by contrasting 'devolve números, não linhas' with returning the task lines themselves.
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?
Explicit guidance is given: 'Para saber COMO um projeto está, prefira systemtask_project_report... use esta quando precisar das tarefas em si, para citar ou editar.' This clearly states when to use this tool versus an alternative, satisfying both positive and negative use cases.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent already knows it is a non-read, non-destructive operation. The description adds value by clarifying behavioral constraints: the task is personal without an assignee, and it does not register demand-specific fields (objetivo, entrega, critério de pronto). This goes beyond simple write semantics and helps the agent understand the tool's limitations.
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 long, front-loaded with the primary purpose, and immediately contrasts with the alternative tool. Every sentence earns its place with no redundant or filler content.
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?
With 6 parameters, reasonable schema descriptions, annotations, and a clear usage boundary, the description covers the essential context. The only minor gap is the absence of information about return values (e.g., whether it returns the created task), but given the simplicity and the effective use of alternative tool guidance, this is not a critical omission.
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 67% (4 of 6 params have descriptions). The description does not add parameter-level detail beyond the schema; it mentions what the task isn't (no assignee, no demand fields) but does not explain the meaning of parameters like priority or description. The schema already covers most fields, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Cria' (creates) and specifies the resource as 'uma tarefa SUA, sem responsável' (your own task, without assignee), clearly distinguishing it from the sibling tool systemtask_demand_create. The contrast is explicit: 'Para trabalho que vai para OUTRA PESSOA, use systemtask_demand_create', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides both when to use ('um lembrete, uma anotação, algo que você mesmo vai fazer') and when not to use ('Para trabalho que vai para OUTRA PESSOA'), naming the alternative tool and explaining why that tool is better suited. This is explicit, actionable guidance.
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?
Adds valuable behavioral context beyond annotations: the agent token intentionally cannot delete tasks, and deletions must be done via the app. This explains the destructiveHint=false annotation and clarifies the safety model. The partial-update behavior is also disclosed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the main purpose and usage pattern, followed by a necessary exclusion. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter update tool with no output schema, the description covers the core semantics, partial update behavior, and the deletion caveat. It does not list all editable fields (e.g., description) but schema covers those, and the main fields are addressed. Sufficiently complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description compensates by mapping key fields: 'data' to due, 'prioridade' to priority, 'estimativa' to estimateMin, 'título' to title, 'marcar concluída' to completed. The instruction to only send changed fields clarifies that all parameters except task are optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies existing tasks, listing specific operations: mark complete, change date, priority, estimate, or title. It distinguishes itself from destructive operations by explicitly stating deletion is not possible through this tool, aligning with the update-focused purpose.
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?
Provides clear guidance: 'Só manda o que muda' (only send what changes) establishes patch semantics. It also explicitly excludes deletion, directing users to the app instead. However, it doesn't name sibling tools like task_create or task_move as alternatives, leaving some room for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context: the tool aggregates personal tasks due today, overdue items, estimated time total, and undated backlog. This goes beyond the annotations by explaining the data scope and what the user will see.
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 value proposition ('what I have today') and then enumerating the contents. Every sentence earns its place: the first lists the data points, the second clarifies the personal scope and gives a usage recommendation. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description carries the full burden of explaining the return value. It does so thoroughly: due today, overdue, estimated time, and undated backlog. The scope boundary ('only mine') and the 'start here' guidance make the tool's place in the workflow clear, especially relative to the sibling tools.
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 zero parameters and schema coverage is 100%, so the baseline for parameter semantics is 4. The description doesn't need to explain parameters, and it doesn't try to; it focuses on the output contents instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('O que EU tenho para hoje') and clearly defines the resource: a personal daily brief. It distinguishes itself from siblings by emphasizing the personal scope ('Traz só o que é meu') and enumerates exactly what it includes (due today, overdue, estimated time, undated backlog). This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Comece o dia por aqui' (start the day here), establishing when to use it. It also gives a clear exclusion: tasks assigned to another person are not part of this view ('tarefa atribuída a outra pessoa é o dia dela'), though it does not name an alternative tool. This is clear context without explicit sibling references.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds value beyond annotations by stating the scope ('todos os projetos que você enxerga') and listing the data aspects included (progress, overdue, no owner, no date). It does not discuss return format or pagination, but the annotation coverage lowers the burden.
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?
Two short sentences, front-loaded with the core purpose and followed by a usage directive. No filler or redundant information; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter list tool with no output schema. The description provides the overview scope, the data points returned, and when to call it, which is sufficient for an agent to select and invoke it correctly. Its sibling tools address more specific needs, but the description clearly directs the agent to use this for broad status questions.
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 zero parameters, so schema description coverage is trivially 100%. With no parameters to document, the baseline is 4; the description doesn't need to add parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Visão geral de TODOS os projetos que você enxerga' clearly identifies this as a list/overview tool. It distinguishes itself by being the first tool to call for a status overview or to find a project id/name, separating it from sibling project_report and project_risks tools.
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?
It explicitly states two trigger conditions: use when the question is 'como estão as coisas?' or when needing to discover a project name/id. This is clear, actionable guidance, but it does not mention when not to use or name alternatives, so it stops short of a perfect 5.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the tool returns the complete task including subtasks, and explains that lists truncate text on purpose. This adds behavioral context beyond the annotations, though it doesn't describe potential limitations or edge cases. The description aligns with annotations, no contradiction.
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 only two sentences, no redundant words. It front-loads the core behavior first, then gives a precise usage trigger. Every sentence earns its place, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is fully adequate. It explains the return value (complete task, subtasks) and when to use it. The output schema is absent, but the description compensates by summarizing the output contents. Annotations cover safety, so no further context is needed.
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 covers the single parameter 'task' thoroughly with a description ('O id da tarefa (o número que aparece como #123).') and a minimum value. Schema description coverage is 100%, so the description does not need to add much. The tool description reinforces the parameter's role by linking it to retrieving the full task, but no additional semantics are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'A tarefa COMPLETA: título e descrição sem corte, mais as subtarefas', indicating it retrieves a full task with all details. It distinguishes itself from sibling tools by emphasizing the complete, untruncated nature versus lists that cut off text. The verb is implicit but the resource and scope are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use sempre que o título aparecer cortado com "…" nas listas e você precisar do texto inteiro'. It clearly tells the agent when to invoke this tool (when truncated titles are seen) and explains that tables truncate intentionally, making this tool the solution. It does not mention when not to use, but the trigger is specific and actionable.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds useful behavioral context, such as including usernames in the output and revealing that the assignment API rejects non-members, which helps the agent understand why listing members is important. However, it does not detail pagination or ordering, so it stops short of a 5.
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 no filler. The key content is front-loaded (what the tool returns), followed by a concise usage guideline. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description provides sufficient context: what is returned (members with usernames), when to use it, and a consequence of misuse. Combined with annotations, this is complete for its complexity.
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 covers 100% of parameters with a rich description for 'project' (accepts name or ID, examples like 'Vendas', 'the city'). The description adds no additional parameter information, so the baseline of 3 is appropriate per the rubric.
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 'Os membros do projeto, com o nome de usuário' clearly identifies the tool as returning project members with usernames. It effectively distinguishes this tool from siblings like projects_list (projects) and tasks_search (tasks), and the title 'Quem participa de um projeto' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use antes de atribuir uma demanda quando não souber quem participa' (use before assigning a task when you don't know who participates). It also mentions the consequence of not doing so — 'atribuir a quem não participa é recusado pela API' — which provides strong practical guidance.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: the 92-day maximum period and the explicit highlighting of people without demand. This goes beyond the annotations by disclosing specific output highlights and a constraint not evident from schema or annotations. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences that each earn their place: the first states the core outputs, the second highlights the unique 'without demand' feature and its use case, and the third gives a specific limit. It is front-loaded with the most important information and has no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, one required) and the presence of readOnly and destructiveHint annotations, the description is complete enough. It explains the output conceptually (open, delayed, completed, estimated hours, and idle people), mentions the key limitation (92-day max period), and the required project parameter is evident from the schema. No output schema is present, but the description adequately covers what the user can expect.
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% (all three parameters have descriptions), so the baseline is 3. The description adds extra semantic value by stating 'Período máximo de 92 dias' (maximum period of 92 days), which imposes a constraint on the 'from' and 'to' parameters not present in the schema. This enriches parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Quanto cada pessoa tem em aberto, quanto atrasou, quanto concluiu no período e quantas horas estimadas carrega' (how much each person has open, delayed, completed, and estimated hours). It also explicitly distinguishes from siblings by highlighting the unique feature 'Quem está SEM DEMANDA aparece explicitamente' (who is without demand appears explicitly), answering a specific question ('quem posso acionar agora?'). This is a specific verb+resource+scope description.
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 the tool: it answers the question 'quem posso acionar agora?' (who can I reach out to now?), indicating a use case for finding idle team members. It mentions a period limit of 92 days, which is relevant for selecting appropriate time ranges. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false), the description discloses important side effects and constraints: only one assignee, assigning another swaps the previous one, null removes, and the person must be a project member. This adds valuable behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: three sentences cover the core rule, the swap behavior, and the clearing mechanism. Every sentence provides distinct, necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema, the description covers the essential behaviors, prerequisites, and side effects. It lacks explicit return/error information, but this is not critical for a straightforward assign operation and the annotations plus schema already fill in key structured 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 schema already has full descriptions for all three parameters (task, project, assignee). The description adds semantic depth by explaining that project is where the username is resolved and that the person must participate in that project, which goes beyond the schema's literal field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Definir (ou tirar) o responsável') and clearly states it sets or removes the assignee of a task. It also highlights the uniqueness constraint ('UMA pessoa é responsável... não existem dois'), which distinguishes it from the general update tool (systemtask_task_update) and other siblings.
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 explains when to use the tool (to assign or remove an assignee) and provides key usage rules: marking another person swaps, null clears, and the person must be in the project. It does not explicitly name alternatives, but the context is clear that this is the dedicated tool for assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by revealing the return contents (account and timezone) and frames the tool as a diagnostic aid for auth issues. This is beyond what annotations provide and fully discloses 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the main function, the second provides usage guidance. No unnecessary words, front-loaded content, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only diagnostic tool with no parameters and no output schema, the description is complete. It explains what the user gets (account and timezone) and exactly when to invoke it, making it self-contained and actionable.
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 zero parameters, so there is no parameter ambiguity. The description does not need to explain parameters, and the baseline for 0-param tools is 4. The description adds no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it confirms the connected account and the timezone used in reports. It uses a specific verb ('confirma') and resource, and it is distinct from all sibling tools, which are task/team/project management operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use the tool: at the beginning if there is doubt about which account the token opens, or if another tool fails due to authentication. This gives clear context and implicit exclusions, matching the bar for explicit usage guidance.
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:

[![system-task-mcp MCP server](https://glama.ai/mcp/servers/luis1amaral/system-task-mcp/badges/card.svg)](https://glama.ai/mcp/servers/luis1amaral/system-task-mcp)

Score Badge

Copy to your README.md:

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

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