Flow Relay MCP Server is a project-aware, multi-tenant MCP server that connects AI clients to the Flow Relay platform for tracking, summarizing, and sharing software development activity across tools. Tools are organized into:
Project Management: Get workspace context, list projects, set an active project scope, and manage integrations and untracked resources.
AI Insights & Handoffs: Generate AI handoffs summarizing recent activity; produce cross-source correlation insights, onboarding briefs, architecture insights, and release notes/PR descriptions; and answer free-form questions grounded in the codebase and recent activity (credit costs vary by insight).
Content Listing & Filtering: List existing handoffs, insights, digests, and raw events; retrieve real filter options (resources, branches, event types, priorities) for precise content generation.
Discord Integration: List Discord channels and send messages, optionally attaching generated handoffs or insights as Markdown files.
Multi-Tenancy: Scope operations to specific projects using a project_id or a session-wide active project.
Requires configuration with a FLOWRELAY_API_KEY (optionally a default project ID and base URL).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Flow Relay MCP Server Generate a handoff for the active project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Flow Relay MCP Server adds project-aware, multi-tenant Flow Relay tools to MCP clients such as Claude Desktop and Claude Code.
It connects to Flow Relay API v1 using an API key and supports:
Project scope (personal project or organization project). Every handoff and AI insight is tied to a project. Events and integrations remain user-level.
Name: @flowrelay/mcp-server
Version: 1.0.16
Related MCP server: Automatisch MCP Server
The server currently exposes these tools:
get_workspace_context
list_projects
set_active_project
list_filter_options (lists the selectable resources, branches, event types and priorities per source for a project – call this before generating so handoff/insight filters use real values instead of guesses; also reports whether Figma is selectable, since Figma requires the project's processing region to be Global)
list_handoffs (returns project-specific handoffs, or an aggregated view of all accessible project handoffs if no project is active; filter by status: active, archived, or all)
ask_project (ask a question about a project and get an answer grounded in codebase, baselines and 14 days of activity; 2 credits per question)
generate_handoff (processed asynchronously, and the server automatically polls until the job finishes. Requires active project or project_id. Accepts per-source filters: projects, eventTypes, branches, priorities.)
generate_correlation_insight (accepts per-source filters)
generate_onboarding_brief (accepts per-source filters)
generate_architecture_insight (accepts per-source filters)
generate_release_notes (generates release notes or PR descriptions from code activity; accepts per-source filters)
list_digests (lists past scheduled activity digests for a project)
list_insights
list_integrations
list_events
list_untracked_resources (lists event-producing resources not scoped to any project – useful for discovering untracked activity)
discord_list_channels
discord_send_message (plain text, or a handoff/insight by id or last_* – last_handoff, last_correlation, last_onboarding, last_architecture, last_release_notes – rendered to Markdown and attached as a .md file)
Required:
FLOWRELAY_API_KEY
Optional:
FLOWRELAY_PROJECT_ID
FLOWRELAY_BASE_URL
If FLOWRELAY_PROJECT_ID is set, it becomes the default project context for project-aware tools unless you override it per call.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"flowrelay": {
"command": "npx",
"args": ["-y", "@flowrelay/mcp-server"],
"env": {
"FLOWRELAY_API_KEY": "fr_your_api_key_here",
"FLOWRELAY_PROJECT_ID": "your_project_id"
}
}
}
}Every handoff and insight is tied to a project; you need an active project (set_active_project) or project_id. Events and integrations remain user-level.
You can select a project during the MCP session with set_active_project.
You can override scope per call by passing project_id where supported.
Recommended flow:
Call get_workspace_context
Call list_projects
Call set_active_project
Run handoff and query tools in the selected scope
From this folder:
npm install
npm run buildCreate a tarball package:
npm packError: Missing FLOWRELAY_API_KEY
Set FLOWRELAY_API_KEY in your MCP client configuration.
Project not found or inaccessible
Run list_projects and use one of the returned IDs.
No events or handoffs returned
Verify active scope and data availability in that scope.
Documentation & Platform: https://www.flowrelay.it
Copyright © 2026 Adriano Sorbello (@atrisorb). All rights reserved.
Distributed under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later). See LICENSE for more information.
Ask one question about a project and get an answer grounded in its indexed codebase, connected baselines and last 14 days of activity. Answers synchronously – there is no job to poll. Costs 2 credits per question, so prefer list_handoffs / list_insights when an existing artifact already answers it.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question, 1-2000 characters. | |
| project_id | No | Project scope. Omit to use the active project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses synchronous execution, credit cost, and temporal scope (last 14 days). While it doesn't detail error conditions or data freshness guarantees, the coverage is sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. The action is front-loaded, and the critical usage guidance (cost and alternatives) is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description does not specify the format of the answer (e.g., text, structured). It also omits error scenarios (e.g., project not found, credits insufficient). While the core function is clear, completeness is slightly lacking for a QA tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (question, project_id) documented. The description adds no extra semantics beyond the schema's existing descriptions, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('ask'), resource ('project'), and scope ('grounded in its indexed codebase, connected baselines and last 14 days of activity'). It distinguishes from sibling tools like list_handoffs and list_insights by emphasizing synchronous execution and credit cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus alternatives: 'prefer list_handoffs / list_insights when an existing artifact already answers it.' It also clarifies behavior (synchronous, no polling) and cost (2 credits), providing clear guidance on when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the text channels in the Discord server connected to this account, each with its id. Call this to get a channel_id before discord_send_message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it lists text channels and returns IDs, but lacks details on authentication, rate limits, or behavior if no server is connected. For a simple list tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. The purpose is front-loaded, and every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description fully covers what the tool does and why it is used. It is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by explaining that the output includes IDs, compensating for the lack of an output schema. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists text channels with their IDs, directly linking to its use before discord_send_message. It distinguishes from siblings by specifying 'text channels' and the intended follow-up action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling this before discord_send_message to obtain channel_id, providing clear context of use. Does not include exclusions or alternative tools, but the guidance is sufficient for its simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send to a Discord channel in your connected server. Provide exactly one of: content (inline text); handoff_id or insight_id (sends that artifact, rendered to Markdown, as a .md file attachment); or artifact (last_handoff / last_correlation / last_onboarding / last_architecture / last_release_notes, with project_id) to send the latest active artifact of that kind.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Inline message text. Mutually exclusive with handoff_id / insight_id / artifact | |
| artifact | No | Send the latest active artifact of this kind. Requires project_id | |
| channel_id | Yes | Discord channel id from discord_list_channels. | |
| handoff_id | No | Id of a handoff (from list_handoffs) to render and attach as a .md file | |
| insight_id | No | Id of an insight (from list_insights) to render and attach as a .md file | |
| project_id | No | Project UUID. Required only when artifact is set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains that handoff and insight artifacts are rendered to Markdown and attached as .md files, which is a key behavioral detail. It does not cover error cases or side effects, but the core action is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. Every sentence adds essential information: purpose, parameter options with constraints, and artifact rendering details. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a moderate number of parameters (6) and no output schema, the description adequately covers input constraints and behavior. It could optionally mention return behavior (e.g., message ID or success status), but the current detail is sufficient for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 6 parameters (100% coverage), but the description adds significant value by clarifying the mutual exclusivity constraint and the specific rendering behavior for handoff/insight IDs. This goes beyond the schema's basic type/enum info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('Discord channel'), and clearly delineates the different types of content that can be sent (inline text, handoff/insight artifacts, predefined artifact types). This distinguishes it clearly from sibling tools like discord_list_channels or generate_handoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that exactly one of the four content options must be provided, which guides parameter selection. It also references related tools (handoff_id requires list_handoffs, artifact requires project_id). However, it does not explicitly mention when to use this tool over others, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an architecture insight: trade-offs, risks, patterns and recommendations inferred from the project's code activity (requires a connected code source – github, gitlab, bitbucket or azure_devops). This is the deepest and most expensive insight (it runs extended reasoning). Use for technical review of architectural direction. Runs synchronously and returns Markdown. Consumes credits, charged once on success. Call list_filter_options before using filters.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Per-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing. | |
| sources | No | Restrict to these source ids. Unknown ids are rejected with 400. | |
| max_events | No | Cap on events processed (1-1000, default 250). | |
| project_id | Yes | Project id from list_projects to generate the insight for. | |
| lookback_days | No | Days of history to review (1-365, default 14). | |
| focus_question | No | A specific architectural question or component to investigate (e.g. "is the billing layer coupled to providers?"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses synchronous execution, Markdown return, credit consumption charged on success, extended reasoning, and dependency on code sources. This provides adequate behavioral context beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, and contains no redundant information. Every sentence contributes essential context (cost, prerequisites, usage).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested filters, multiple parameters, missing output schema and annotations), the description covers key aspects: prerequisites, synchronous nature, credit charge, and filter pre-call. It could mention that the insight is saved/listable, but overall it is complete enough for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful guidance: focus_question for specific queries, filters require list_filter_options, sources restrict to ids, and defaults for max_events and lookback_days. This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates an architecture insight with specific content (trade-offs, risks, patterns, recommendations) and distinguishes from sibling tools by noting it's the deepest/most expensive and for technical review of architectural direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites (connected code source like github, gitlab, etc.), advises calling list_filter_options before using filters, and indicates the use case (technical review). It does not explicitly exclude other use cases, but context with siblings implies when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cross-source correlation insight: finds related events across different sources (e.g. a Slack thread, a Jira ticket and the PR that resolved it) and surfaces the links, patterns and open threads. Use when the user wants to understand how activity connects across tools. Runs synchronously and returns Markdown. Consumes credits, charged once on success. Call list_filter_options before using filters.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Per-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing. | |
| sources | No | Restrict to these source ids (e.g. "github", "slack"). Unknown ids are rejected with 400. | |
| max_events | No | Cap on events processed (1-1000, default 150). | |
| project_id | Yes | Project id from list_projects to generate the insight for. | |
| lookback_hours | No | Hours of activity to analyze (1-2160, default 168 = 7 days). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses synchronous execution, Markdown return, and credit consumption. With no annotations, these details add valuable transparency beyond purpose. Could mention error handling or rate limits to reach 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose (what, when, how, prerequisite). No fluff, front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose, behavior, and key prerequisite. With no output schema, the 'returns Markdown' is helpful but lacks detail on response structure. Adequate for a synchronous tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no new parameter semantics beyond a usage hint for filters. The schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a cross-source correlation insight, uses specific verb 'generate', and distinguishes from siblings like 'generate_architecture_insight' by focusing on cross-source links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context ('Use when the user wants to understand how activity connects across tools') and a prerequisite ('Call list_filter_options before using filters'). Lacks explicit alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a project handoff: an AI summary of recent activity, key changes, decisions, open questions and next steps for a project. Runs synchronously – waits for completion (tens of seconds) and returns the finished Markdown. Requires an active project (set_active_project) or an explicit project_id from list_projects. Consumes credits from the user's plan, charged once on success – prefer list_handoffs to read an existing one before generating a new one. To scope it, pass sources and/or filters (call list_filter_options first for valid values); omit both to use the project's saved scope preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Per-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing. | |
| sources | No | Restrict to these source ids (omit for all connected sources). Unknown source ids are rejected with 400. | |
| project_id | No | Project id from list_projects. Overrides the active project for this call; required if no active project is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses synchronous execution (tens of seconds), returns Markdown, credit consumption, and requires active project. Could mention more about error cases or idempotency, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a well-structured paragraph with core purpose upfront. Slightly lengthy due to parameter details, but every sentence adds value. Could be tightened but not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it clearly states returns finished Markdown. References needed prerequisites (active project, list_filter_options) and sibling tools. Adequately prepares the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant value: explains AND-combined filters, lenient matching, project_id overrides, and source omission behavior. Also warns about 400 errors for unknown source ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a project handoff (AI summary) and specifies the verb-resource pair. It explicitly distinguishes from the sibling tool list_handoffs by advising to check for an existing one first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: requires an active project or project_id, advises calling list_filter_options first for valid filter values, and recommends using list_handoffs to avoid unnecessary generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an onboarding brief: a getting-started guide for someone new to the project – key people, key decisions, pitfalls and recommended reading drawn from recent activity. Use when a new team member needs to get up to speed. Runs synchronously and returns Markdown. Consumes credits, charged once on success. Call list_filter_options before using filters.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Per-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing. | |
| sources | No | Restrict to these source ids. Unknown ids are rejected with 400. | |
| focus_area | No | Repository or feature area they will work on. Narrows the brief. | |
| max_events | No | Cap on events processed (1-1000, default 400). | |
| project_id | Yes | Project id from list_projects to generate the brief for. | |
| lookback_days | No | Days of history to review (1-365, default 30). | |
| new_member_role | No | Role/focus of the person being onboarded (e.g. "backend engineer"). Tailors the brief. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses synchronous execution, Markdown output, and credit consumption (charged once on success). It does not detail potential failure modes or rate limits, but covers essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a filter-related instruction. Every sentence adds value: purpose, usage, behavior, prerequisite. No fluff, well front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (including nested objects) and no output schema, the description provides a solid overview. It states the output format (Markdown) and prerequisites. However, it could briefly mention that the brief is generated from recent activity (implied) and the absence of return structure guidance is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds substantial context beyond the schema. It explains the brief's content (key people, decisions, pitfalls) and the dependency on list_filter_options for filters. This enriches understanding beyond raw parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an onboarding brief (a getting-started guide), with specific content like key people, decisions, pitfalls. This distinguishes it from sibling tools like generate_handoff, which is for handing off context to another person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when a new team member needs to get up to speed' and instructs to 'Call list_filter_options before using filters.' This provides clear when-to-use and prerequisite guidance, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate release notes or a PR description from recent code activity (commits, PRs, builds). Runs synchronously and returns Markdown. Consumes 3 credits on success.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository name to scope changes to. | |
| style | No | Output style. | release_notes |
| source | No | Code source id (github, gitlab, bitbucket, azure_devops). | github |
| filters | No | Per-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing. | |
| project_id | Yes | Project id from list_projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden, and it usefully states the sync execution, Markdown output, and credit cost. However, it omits error behavior, permission requirements, or potential side effects, but the disclosed traits are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, front-loaded with purpose, then execution details and credit cost. Every sentence adds essential information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested filter object, no output schema), the description is somewhat minimal. It doesn't explain the need to call 'list_filter_options' before using filters, nor the structure of the Markdown output. Coverage is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The tool description adds no extra parameter details, aligning with the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates release notes or PR descriptions from recent code activity, making the purpose highly specific. The verb 'generate' and resource 'release notes or PR description' are explicit. It distinguishes from siblings like 'generate_handoff' by specifying the focus on code activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating release notes or PR descriptions but does not provide explicit guidance on when to use it over alternatives, such as 'generate_handoff' for handoffs. No 'when-not-to-use' or context-specific advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current Flow Relay context: personal vs business mode, number of organizations and accessible projects, the active project scope and the caller's role. Good first call to orient yourself before other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists the specific information returned (mode, org count, project count, active scope, role). No annotations provided, so description carries full burden; it adequately discloses the read-only nature and content but does not mention any potential side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first lists outputs, second gives usage guidance. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Perfect completeness for a 0-parameter read tool with no output schema. Lists all returned fields and provides usage context, sufficing for agent orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline score of 4 applies. Description adds value by explaining what the tool returns, which is relevant for an info tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows the current Flow Relay context including mode, organizations, projects, active scope, and caller role. 'Show' verb paired with 'workspace context' resource. Easily distinguished from siblings like list_projects or set_active_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Good first call to orient yourself before other tools,' providing clear guidance on when to use it as an initial exploration step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List past scheduled activity digests for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max digests to return (1-50, default 10). | |
| project_id | Yes | Project id from list_projects. |
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 but only states the basic function. No information on read-only nature, authorization, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the action. It is appropriately brief for a simple listing operation, though could add more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details about the output format, pagination, or the nature of 'digests'. Given the complexity (2 params, no output schema), additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds no additional parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (past scheduled activity digests), and scope (for a project). It distinguishes from sibling tools like list_projects and list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No mention of prerequisites, exclusions, or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent raw context events (individual pieces of tracked activity: a push, a message, an issue update) newest first. Use it to inspect the underlying signal a generation would draw on, or to check whether a source is producing data. With a project scope it is limited to that project's bound resources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events to return (1-100, default 20). | |
| source | No | Restrict to one source id (e.g. "github"). Unknown ids are rejected with 400. | |
| project_id | No | Project id (from list_projects) to scope to. Omit (or rely on the active project) for the owner's personal-stream events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions ordering ('newest first') and scoping ('limited to that project's bound resources'), but omits details like pagination beyond the limit parameter, idempotency, error handling (except schema-infused source rejection), or rate limits. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and use cases with no redundant information. Every sentence earns its place, and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, no output schema, and no annotations, the description effectively covers the tool's core functionality, usage scenarios, and project scoping. It is mostly complete for an agent to decide when and how to use it, though it could mention basic error behavior (e.g., rejection of unknown source ids) which is only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about using parameters to inspect signal or check source activity, and clarifies project_id scoping ('limited to that project's bound resources'). This adds modest value but does not exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and resource 'raw context events', with examples like 'a push, a message, an issue update'. It also mentions sorting 'newest first' and project scoping, making the purpose clear. However, it does not explicitly differentiate from siblings like 'get_workspace_context' or 'list_insights', which could cause confusion for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it to inspect the underlying signal a generation would draw on, or to check whether a source is producing data', providing clear use cases. It does not state when not to use or name alternatives, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the real per-source filter values (resources, branches, event types, priorities) available for a project. Call this BEFORE generate_handoff or any generate_*_insight so the "filters" argument uses real values instead of guesses. Pass a resource id into filters[source].projects, a branch name into .branches, an event type into .eventTypes, a priority into .priorities.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project scope. Omit to use the active project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes the action (listing values) but does not disclose side effects, performance, or authentication needs. Mentions dependency (call before generation tools) which adds some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states purpose, second gives usage context and parameter guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is sufficiently complete. It covers what the tool does, when to use it, and how to use the parameters. Could optionally describe the return format, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (project_id). Description repeats the schema info ('Project scope. Omit to use the active project.') without adding new meaning. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists real per-source filter values (resources, branches, event types, priorities) for a project. Uses specific verb 'List' and resource 'per-source filter values'. Distinguishes itself from sibling generation tools by positioning itself as a preparatory call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: before generate_handoff or any generate_*_insight. Explains why: to get real values for the 'filters' argument. Does not mention when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing handoffs (newest first) with their full content, across all accessible projects or one project. Use this to read what has already been generated before spending credits on a new generate_handoff. Each row's id can be sent to Discord via discord_send_message.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max handoffs to return (1-50, default 10). | |
| status | No | active = current handoffs, archived = superseded ones, all = both. | active |
| project_id | No | Project id (from list_projects) to scope to. Omit to span every accessible project, or rely on the active project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it lists handoffs with full content, newest first, across projects. Lacks details on data freshness, access control, or if it's read-only. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose front-loaded, usage guidance in second sentence. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with 3 parameters and no output schema, the description covers scope, order, and usage hint. Missing error handling or pagination details, but still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is documented. Description adds context like 'across all accessible projects' for project_id and 'newest first' for ordering, but doesn't add significant detail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list', resource 'handoffs', order 'newest first', scope 'across all accessible projects or one project', and content 'full content'. Distinguishes from siblings like generate_handoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before spending credits on generate_handoff, providing a clear when-to-use and alternative. Does not cover when not to use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing insights for a project (newest first) with their content. Use this to read what has already been generated before spending credits on a new generate_*_insight. Each row's id can be sent to Discord via discord_send_message.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to one kind. Omit for all kinds. | |
| limit | No | Max insights to return (1-50, default 20). | |
| status | No | active = current, archived = superseded, all = both. | active |
| project_id | Yes | Project id from list_projects to list insights for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses ordering (newest first), that content is included, and implies a non-destructive read operation. Mentions credits as a resource to conserve. Lacks details on pagination or rate limits, but adequate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First states the core function with ordering and content. Second provides actionable advice. No filler, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, description covers main purpose, ordering, content, and a sibling use case (discord). Missing details on output format or pagination defaults, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage) with descriptions. Description does not add extra meaning beyond the schema; it mentions 'project' but no elaboration on kind, limit, or status. Baseline 3 as schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'List existing insights for a project' with ordering 'newest first' and content details. It distinguishes from generate_*_insight siblings by advising to check existing insights before generating new ones, and mentions integration with discord_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool to read existing insights before generating new ones to save credits. Provides context for usage with discord_send_message. Does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected integrations. With a project scope it returns the resources bound to that project plus their health (connection status, provider coverage); without one it returns the sources the API key owner has connected. Use it to check what data a generation can draw on.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project id (from list_projects) for project-scoped resources. Omit (or rely on the active project) for the owner's connected sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the behavior difference based on the presence of a project_id and mentions returned data (health, provider coverage). It lacks details on authorization, rate limits, or output format, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states the action, the second provides context and use case. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately describes what is returned in both modes (resources with health vs connected sources). It covers all necessary information for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, and the description adds significant value by explaining the semantic difference between providing or omitting project_id, going beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List connected integrations' and distinguishes between two scopes (project vs owner), making the tool's purpose specific and easily understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool 'to check what data a generation can draw on', providing a clear use case. However, it does not mention when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every project the API key can access (personal and organization), each with its id, scope and the caller's role. The id returned here is what you pass as project_id to the generate_* and list tools – start here whenever you need one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states what data is returned but does not mention if the operation is read-only, has any side effects, or any rate limits. The agent can infer it is a read operation from 'list', but explicit confirmation is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the purpose and usage guidance with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and output usage. However, it lacks details on potential pagination or limits on the number of projects listed, which could be important for the agent. Given low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is effectively 100%. The description does not need to add parameter semantics. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (list), the resource (every project accessible by API key), and the output fields (id, scope, role). It also explains the use of the returned id, distinguishing this tool as the entry point for project IDs among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'start here whenever you need one' suggests using this tool to obtain project IDs before other tools. However, it does not explicitly exclude cases when to use sibling tools like list_untracked_resources or list_integrations, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active resources (repos, channels, boards) that produced events recently but are not yet assigned to any project. Use it to spot data the user connected but has not organized into a project yet – mapping them (in the web dashboard) makes their events available to generations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the tool as a listing operation (read-only), but does not mention potential side effects, permissions, or output structure. Adequate for a simple 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences immediately convey what the tool does and why to use it, with no redundant or extraneous information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description provides sufficient context: what is returned (list of untracked resources), how to use the results (map them in dashboard), and the benefit. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%, so the baseline score is 3. The description does not need to add parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active resources (repos, channels, boards) that are not yet assigned to any project, using strong verb 'list' and specific resource types, differentiating from sibling tools like list_projects and list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it to spot data...' and explains the context (identifying unorganized data), providing clear guidance on when to use it. It lacks explicit exclusions or alternative tools but is sufficient for the simple list purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active project so later tools can omit project_id (a convenience for a multi-step session on one project). Set it once from a list_projects id, then call generate_handoff / list_events / etc. without repeating project_id. Not required if you always pass project_id explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | Clear the active project. Generation then requires an explicit project_id again. | |
| project_id | No | Project id (from list_projects) to set as active. Omit, or set clear, to unset it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the convenience behavior and explains the 'clear' parameter to unset. Lacks detail on state persistence scope (e.g., session lifetime), but adequate for a simple state-setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, efficient with no waste. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple 2-parameter tool with no output schema. Covers purpose, usage, parameter semantics, and relationship to other tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds meaning: explains that project_id comes from list_projects, and clarifies the 'clear' parameter behavior. Goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the active project so later tools can omit project_id'. It uses a specific verb ('Set') and resource ('active project'), and distinguishes from siblings by explaining it's a convenience for multi-step sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ('Set it once from a list_projects id, then call generate_handoff / list_events / etc.') and when not to use ('Not required if you always pass project_id explicitly'). Also mentions alternative approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.14ask_projectdiscord_list_channelsdiscord_send_messagegenerate_architecture_insightgenerate_correlation_insightgenerate_handoffgenerate_onboarding_briefgenerate_release_notesget_workspace_contextlist_digestslist_eventslist_filter_optionslist_handoffslist_insightslist_integrationslist_projectslist_untracked_resourcesset_active_projectScored across 18 tools
Each tool has a clearly distinct purpose, with separate verbs (list, generate, set, get, ask, discord_list, discord_send) and noun targets (projects, resources, handoffs, events, insights, etc.). There is no overlap that would confuse an agent.
All tool names use consistent lower_snake_case with a clear verb_noun pattern. The discord_ prefix is a logical grouping and does not break consistency. No mixing of conventions.
18 tools is well-scoped for a server providing project management, AI-generated summaries, insights, and Discord integration. The count is balanced and each tool serves a necessary function without bloat.
The tool surface covers core workflows: context retrieval, artifact generation, listing, filtering, and Discord output. Minor gaps exist (no tool to manage untracked resources or update project settings), but these do not prevent agents from accomplishing primary tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
Connect AI assistants to Stellary projects, boards, documents, and governed agent workflows.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/atrisorb/flowrelay-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
