teamhub-mcp

by imortis

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Each tool maps to a distinct resource/action in the task/plan/file-note lifecycle, but get_context, get_plan, and get_handoff_brief have overlapping retrieval purposes. The descriptions mitigate this with explicit guidance (prefer get_handoff_brief for handoffs), so misselection is unlikely but not impossible.
Naming Consistency5/5
All tools use clear snake_case verb_noun names like get_context, declare_task, update_plan, and check_file_before_edit. Retrieval consistently uses get_, while mutations use declare/claim/update/log/record, forming a predictable pattern.
Tool Count5/5
12 tools is well-scoped for a team-coordination server: task lifecycle, plan management, file annotations, activity logging, and context aggregation are each represented. There is no obvious bloat or thinness.
Completeness4/5
Core workflows are covered end-to-end: task declaration/claiming/status updates, plan read/write, file rationale notes, freshness checks, and handoff context. Minor gaps exist—such as no way to delete or retract a file note—but agents can work around these without dead ends.
Average 4.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the note is pinned to the current commit and that consumers can check whether the file has changed to judge trustworthiness. However, it does not disclose whether repeated calls append or overwrite notes, what happens if the file changes, or any permission/mutation implications.
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 no filler. The core action is front-loaded, and the second sentence adds only the high-value anchoring and trustworthiness context. Every clause earns its place.
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?
The description covers the tool's purpose and its main downstream interaction with get_file_history, which is helpful. However, it leaves important operational gaps: parameter semantics for memberName, repeated-call behavior, and whether the note is one-per-file or one-per-commit. For a four-parameter tool with no output schema and no annotations, this is a moderate but not complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the absence of parameter documentation. It partially does by mapping 'what you did, why' to the summary/reasoning fields and implying filePath via 'file', but it gives no meaning for memberName and leaves the relationship between summary and reasoning ambiguous.
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 names a specific verb and resource: attach a rationale note to a file. It also clarifies the content (what you did, why) and distinguishes the tool from siblings like get_file_history by describing the note as a commit-anchored comment rather than a retrieval or task-tracking operation.
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 'a file you finished touching' gives a clear trigger condition for when to use the tool. It also references get_file_history as the mechanism through which the note will later be surfaced, giving the agent a meaningful context signal. It does not explicitly list exclusions or alternatives, but the timing guidance is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral burden and does a good job: it discloses the recentActivityNearby return value, explains it contains real recent commits from others, and explicitly notes that a non-empty list does not block the claim. It could go further on persistence, permissions, or side effects, but the core behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose first, then the key return value, then the important caveat about non-blocking behavior. No wasted words and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal input schema, the description is fairly complete for a simple claim action. It explains purpose, source of the task, what the return contains, and how to interpret it. The main missing piece is parameter semantics, particularly memberName, and clearer routing against sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little parameter-level meaning. It implies taskId comes from get_context, but never explicitly names or explains taskId, and memberName is entirely absent from the description. This is a meaningful gap for two parameters.
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 ('claim') and resource ('existing task'), and clearly states the purpose: signaling to teammates that you're working on it. It also points to get_context as a source of the task, helping differentiate from creation-oriented siblings like declare_task.
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 the usage context: after getting a task from get_context and before diving in. However, it never explicitly states when not to use this tool or names alternatives like declare_task, update_task_status, or log_activity, so the agent must infer the boundary between these siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool deterministically bundles multiple data categories, includes abandoned tasks specifically to avoid redoing dead ends, and provides anchor-verified file history. It does not mention auth, rate limits, or exact output structure, but it gives a strong sense of what happens and why.
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 primary use case and then packs in detailed content about what the brief contains and why. It is a long, dense sentence, but each clause contributes useful context about the tool's behavior or rationale.
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 that there is no output schema and no annotations, the description does a good job of explaining what the tool returns by enumerating the bundled content areas and the reasoning behind them. It could be more complete by mentioning the sibling get_context tool or explicitly describing the response shape, but it provides enough for 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value to the scope parameter by giving a concrete example ('frontend') and explaining that it focuses the brief on one area. The doneLimit parameter is not mentioned in the description, but the schema already documents its default and purpose.
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 a specific action and resource: getting a bundled handoff brief containing requirements, tasks, completions, and file history. It is very clear about the intended session contexts, but it does not explicitly distinguish itself from sibling tools like get_context, instead differentiating against manual context assembly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: picking up someone else's work or starting a session on a shared repo, and it explicitly tells the agent to use this instead of assembling context from several calls. It does not name alternative sibling tools or provide a 'when not to use' condition, but the guidance is clear 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?
With no annotations, the description carries the full behavioral burden. It discloses what the tool returns (status transitions, actor, and timing) and uses 'See' to imply a read-only operation. It does not explicitly state non-mutation or edge-case behavior, but for a history getter this is mostly sufficient.
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 one focused sentence that front-loads the core behavior and adds a useful usage example after the dash. Every clause adds value, with no filler 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?
Given one required parameter, no output schema, and no annotations, the description provides sufficient context: what is returned, who/when, and when it is useful. Minor gaps include no explicit ordering or mention of how missing taskIds are handled, but these do not prevent correct 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 0% and the description does not explicitly define taskId or its format. However, the phrase 'a task went through' indirectly maps the taskId parameter to the task whose history is returned, and the single self-explanatory parameter limits 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 identifies the action and resource: seeing every status transition for a task, including who made each change and when. It is clearly about task status history rather than current state, but it does not explicitly differentiate itself from sibling tools like get_file_history or get_context.
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 a concrete when-to-use condition: when a task's current state alone doesn't explain how it got there, with an abandoned/reclaimed example. It does not mention alternatives or when not to use the tool, so it stops short of a full routing guide.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It goes beyond the tool name by explaining the anchorStatus values and their practical implications ('re-read the file before trusting the note'), which is genuinely useful. It does not mention side effects or error behavior, but 'get' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core purpose front-loaded and the status semantics compactly explained in the second. Every phrase contributes information; no padding or restatement of the title.
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 one-parameter read tool, the description covers purpose, usage timing, and the key return nuance (anchorStatus). The main gap is the lack of filePath semantics and a fuller response shape, but the definition is sufficient for selection and likely invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, filePath, has no schema description (0% coverage), so the description was expected to compensate. It says 'a specific file' but provides no path format, relative/absolute distinction, or workspace context. An agent would still need to guess the accepted path form.
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?
States a specific verb ('Get') and resource ('rationale trail for a specific file'), and clearly defines what the history contains: what teammates did and why. This distinguishes it from sibling tools like get_task_history or check_file_before_edit, which target different resources or current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as something to use 'before you continue' a file, which gives a clear trigger for invocation. It does not name alternative tools or explicitly say when not to use it, but the contextual cue is strong enough for most routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining side effects. It does so by stating that the call broadcasts to teammates, surfaces in recent activity, and is immediately visible so teammates do not rely on stale plans. It does not mention optional-field side effects or persistence details, but the core behavioral impact is disclosed.
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 no filler. The first sentence front-loads the core purpose, and the second adds the only non-obvious usage detail—pivoted semantics and required detail content—without repeating schema information.
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 broadcasting tool with no output schema and no annotations, the description gives enough guidance to call it correctly for the required parameters. The main gap is the undocumented optional parameters 'files' and 'memberName,' but the central behavior and required-input expectations are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, so the description must compensate. It adds meaningful semantics for 'kind' and 'detail' by specifying the pivoted case and what detail should contain. However, 'files' and 'memberName' remain completely unexplained, so the description only partially compensates for the low 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 uses a specific verb—'Broadcast'—and a clear object, 'what you're currently doing.' It also explains the outcome: the activity will appear in get_context/get_handoff_brief calls. This clearly distinguishes it from sibling task-management and planning 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?
The description gives clear context for when to log activity and provides an explicit rule for the 'pivoted' kind: use it when changing approach mid-task without abandoning it outright. It also explains what detail should capture. However, it does not explicitly name alternative tools or state when not to use log_activity versus those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly warns that this is a full-content replacement affecting a shared source of truth read by every teammate's agent, which is crucial context. It does not mention recovery or permissions, but the destructive overwrite nature is well conveyed.
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 focused sentences convey the operation, the precondition, the warning, and the rationale. There is 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 straightforward document-replacement tool, the description covers the essential behavior, the risk of overwriting shared content, and the recommended read-before-write flow. It doesn't describe the return value, but no output schema exists and the operation is simple enough that this is a minor gap.
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 only 33%, with only 'content' described. The description adds useful meaning by mapping the 'doc' parameter to requirements.md or design.md, but it does not clarify the optional 'memberName' parameter, leaving a gap.
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 names a specific verb and resource: it replaces the full content of one plan document (requirements.md or design.md) with new markdown. This clearly distinguishes it from sibling read tools like get_plan and other task-status 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 gives clear procedural guidance: read get_plan first, edit the whole document, and do not append blindly. It does not explicitly enumerate when-not-to-use cases or alternative update paths, so it falls just short of a top score.
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?
There are no annotations, so the description carries the full behavioral burden. It discloses useful traits: the check is fast, single-file, returns anchor-verified notes, includes real commits from the last 15 minutes, and catches mid-session drift. It does not explicitly state side-effect behavior (e.g., read-only) or failure behavior, but 'check' strongly implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the key action and timing, and every sentence earns its place: usage conditions, return contents, and a comparative cost signal. No redundant or filler phrasing is present.
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 one-parameter tool with no output schema and no annotations, the description covers the main invocation context, what is returned, and how it relates to alternatives. It does not specify the exact response structure or how to interpret 'anchor-verified' results, but it provides enough for most agents to call and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the filePath parameter's required format, whether it must be absolute or relative, or any constraints. Phrases like 'single-file' and 'this exact file' merely reinforce the parameter name rather than adding semantic detail an agent would need to invoke it correctly.
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 states a specific action ('freshness check') and resource ('single-file'), and clearly positions the tool as the thing to call immediately before editing a file. It also differentiates from alternatives by naming get_handoff_brief as more expensive and by contrasting against a session-start snapshot.
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 gives explicit conditions for when to use it: 'immediately before editing any file that's part of a shared interface or that you haven't touched yet this session, ESPECIALLY in a long-running session.' It also provides an alternative comparison, noting it is cheaper than get_handoff_brief and catches drift that a session-start snapshot misses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'Read' clearly signals a non-mutating operation, and 'living plan documents' conveys that these are current, maintained artifacts. It adds context about document contents, though it does not describe return format or staleness handling.
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 compact sentences front-load the core action and resource, then add complementary guidance. The phrase 'not just the task list' efficiently disambiguates from sibling tools without unnecessary bulk.
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, parameter-less read tool, the description provides the action, the exact documents, their semantic purpose, and guidance to combine with sibling tools. Nothing required for correct invocation is missing.
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 the schema covers parameter semantics completely. The description adds no parameter-specific detail, but none is needed; the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('Read') on a clear resource ('the two living plan documents') and identifies their contents (requirements and design). It also distinguishes itself from task-list tools by noting 'not just the task list,' which differentiates it from siblings like get_context.
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 explicitly tells the agent to use this tool alongside get_context/get_handoff_brief to understand intent, providing a clear complementary usage context. It does not spell out when not to use it or name alternatives beyond that, so it stops short of fully explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and delivers richly: it discloses that the completion record becomes 'the permanent, queryable design record in .hub/tasks/' that 'feeds get_handoff_brief,' and that uncommittedFileWarnings means the listed files are 'NOT actually committed/pushed yet.' It also reveals the social consequence of abandoning versus silently leaving a task in_progress, which the schema and annotations do not convey. 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?
Roughly 200 words, but the tool has conditional behavior, a nested object, and a side-effect warning, so the length is largely earned. It front-loads the core purpose and highest-stakes rule (done → completion) before the abandon guidance. Some rationale prose, such as 'unlike prose that gets reinterpreted differently by every reader,' is verbose but reinforces a constraint worth emphasizing.
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 state-transition tool with nested parameters and no annotations or output schema, the description covers the essential ground: required shapes, persistence, handoff integration, and the commit warning. The main gaps are the undocumented memberName parameter and no statement of what a successful update returns. An agent still has enough to call it correctly in the common and risky cases.
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 40%, so the description must compensate, and it does for the consequential parameters: it defines the fixed shape of completion (whatWasBuilt, decisions, filesChanged, knownLimitations, nextSteps) and the meaning of 'done' and 'abandoned' states. It does not touch memberName, which remains unexplained in both schema and description, though taskId is self-evident and the gap is limited.
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?
States a specific verb and resource ('Update a task's status') and goes on to define the two status transitions that carry real consequences ('done' with completion, 'abandoned' with abandonReason). The description makes the tool's scope unambiguous against siblings like update_plan, claim_task, and log_activity by the resource it mutates, even without naming them.
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?
Gives explicit conditional guidance: 'When marking a task done, ALWAYS include completion' and 'If you're changing direction WITHOUT finishing... set status abandoned with abandonReason instead of just going quiet.' It also warns against silently leaving a task in_progress indefinitely. It does not name alternative tools or state when to prefer a sibling such as log_activity, 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?
With no annotations, the description carries the burden of disclosing behavior. It transparently states that it fetches from .hub/, what content it returns, and that it pulls the latest from git first. It does not detail failure modes or explicitly label the operation as read-only, but the side effect of the git pull is disclosed, which is meaningful for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences accomplish a lot: the first fronts the primary purpose and content, the second adds the git behavior and the sibling alternation. Every sentence earns its place, with no filler 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 zero-parameter tool with no output schema and no annotations, the description covers the source, the data returned, the git-pull behavior, and the main alternative. It could go slightly further by noting the output shape or failure conditions, but the enumerated content gives an agent a solid mental model of what to 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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool gets a baseline of 4; the description adds no misleading parameter information and focuses on behavior and output content.
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?
States a specific verb ('Fetch') and resource (shared plan from .hub/ plus recent teammate activity), and enumerates the contained data: tasks with status/owner/declared interface. It also names the sibling alternative get_handoff_brief, making it easy for an agent to distinguish this tool from similar context-gathering tools.
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 tells the agent when to use a different tool: 'For picking up someone else's work, prefer get_handoff_brief instead', with a concrete reason (it includes richer handoff-specific context). This is clear routing guidance beyond a generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It explicitly states that the task remains UNCLAIMED, that the tool commits and pushes to '.hub/tasks/', and that it returns both 'conflicts' and 'recentActivityNearby' to catch teammates mid-edit. These are exactly the side effects and behavioral nuances an agent needs to know.
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 states the core purpose and inputs, the second clarifies ownership semantics, the third discloses side effects, and the fourth explains return values and required checks. Every sentence earns its place, and there is no filler 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?
Given the tool has no output schema and no annotations, the description covers most essential operational context: what it writes, what it returns, and what to do next. It names the return fields with explanations, but does not describe the exact structure of 'conflicts' or 'recentActivityNearby', nor any failure modes. For a 5-parameter tool with no schema on return values, this is still a strong, mostly complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description adds meaningful context for the main parameters: 'scope' is defined as file paths, module names, or API routes; 'interface' and 'assumptions' are framed as optional. It does not mention 'memberName', but the schema already documents its default behavior, so this is a minor gap. Overall, the description compensates for the schema's missing parameter details for title and assumptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Propose a task' with title, scope, optional interface, and assumptions. It also names the exact artifact it touches ('.hub/tasks/') and explicitly differentiates itself from the sibling 'claim_task' by noting the task is left unclaimed. This makes it easy for an agent to select this tool over its siblings.
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 says when to use this tool vs. alternatives: call it to propose a task, then call 'claim_task' if you intend to build it yourself, so teammates can otherwise pick it up. It also instructs the agent to check 'conflicts' and 'recentActivityNearby' before proceeding, giving concrete next-step guidance. This is unusually clear usage direction.
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:

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

Score Badge

Copy to your README.md:

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

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