Provides read-only access to Favro project management data, including collections, boards, cards, comments, and checklists.
Click on "Deploy 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., "@favro-mcp find cards about deployment issues in the engineering board"
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.
An MCP server that gives your AI assistant read access to Favro — collections, boards, cards, comments and checklists.
Read-only by design. Every one of the 14 tools issues a GET and nothing else. There is no code path in this package that can create, change, archive or delete anything in your Favro account — a test asserts it on every commit. You are handing over an API token, so that guarantee is the point.
Nothing to install. Point your MCP client at npx:
{
"mcpServers": {
"favro": {
"command": "npx",
"args": ["-y", "favro-mcp"],
"env": {
"FAVRO_EMAIL": "you@example.com",
"FAVRO_API_TOKEN": "your-api-token",
"FAVRO_ORGANIZATION_ID": ""
}
}
}
}Requires Node 18 or newer.
In Favro: profile menu → My profile → API tokens → Create new token. The token pairs with the email address you sign in with; both are needed.
FAVRO_ORGANIZATION_ID is optional. Leave it empty and ask your assistant to run list-organizations — it will return the ids you have access to, and you can either paste one into the config or let the assistant pass it per call.
claude mcp add favro --env FAVRO_EMAIL=you@example.com --env FAVRO_API_TOKEN=your-api-token -- npx -y favro-mcpOr add the JSON block above to .mcp.json in your project root.
Edit claude_desktop_config.json:
macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json
Paste the JSON block above, then fully quit and reopen Claude Desktop — reloading the window is not enough.
Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project) and paste the JSON block above.
Add to .vscode/mcp.json, using servers rather than mcpServers:
{
"servers": {
"favro": {
"command": "npx",
"args": ["-y", "favro-mcp"],
"env": {
"FAVRO_EMAIL": "you@example.com",
"FAVRO_API_TOKEN": "your-api-token"
}
}
}
}Related MCP server: linear-mcp
Tool | Purpose | Required arguments |
| Organizations the account belongs to | — |
| Collections shared with the account | — |
| One collection |
|
| Boards and backlogs, optionally by collection | — |
| One board, with its columns and lanes |
|
| A board's columns |
|
| Cards on a board, in a collection, or in your todo list | one of |
| Full detail on one card |
|
| Find cards by text in their name or description |
|
| A card's comments |
|
| A card's checklists |
|
| Checklist items |
|
| Users in the organization | — |
| One user |
|
Every tool also accepts an optional organizationId to override the configured default.
Variable | Required | Default | Purpose |
| yes | — | The email you sign in to Favro with |
| yes | — | An API token from your Favro profile |
| no | — | Default organization; otherwise pass |
| no |
| Seconds to cache slow-changing entities. |
API term | What you see in Favro |
widget | A board or backlog |
tasklist | A checklist on a card |
task | A single checklist item |
cardId identifies one card on one board. get-card takes this.
cardCommonId identifies the card across every board it appears on. The comment and checklist tools take this.
Both come back from list-cards and get-card.
list-organizations (only when FAVRO_ORGANIZATION_ID is unset)
→ list-collections find the collection
→ list-boards boards in that collection
→ get-board its columns and lanes, in one call
→ list-cards cards on the board or in a column
→ get-card full detail on one card
→ list-card-comments / list-card-tasklists / list-card-tasksListings return up to 100 entities. When more remain, the response carries a cursor:
"pagination": {
"page": 0,
"pages": 3,
"requestId": "...",
"backendId": "...",
"next_page": { "page": 1, "requestId": "...", "backendId": "..." }
}Call the same tool again passing page, requestId and backendId exactly as given. All three are required — Favro routes follow-up pages to the same backend server, and the backendId is what gets them there.
search-cards is a local filter, not a search endpointFavro's API has no card search. search-cards reads cards from a board or collection and filters them by case-insensitive substring on name and description. It reads up to maxPages pages (default 3, maximum 10), each costing one API call, and reports what it covered:
"scan": {
"cards_scanned": 250,
"matches_found": 4,
"pages_read": 3,
"pages_available": 5,
"complete": false,
"note": "Only 3 of 5 pages were searched. Raise maxPages..."
}When complete is false, narrow the scope or raise maxPages rather than treating the result as exhaustive.
Favro's hourly budget is low and plan-dependent — 100/hour on Trial up to 10,000/hour on Enterprise, with list-organizations and the user tools sharing a separate 50/hour budget. Every response carries a rate_limit block showing what is left.
To conserve calls, organizations, users, collections, boards and columns are cached for FAVRO_CACHE_TTL seconds. Cached responses are marked "cached": true. Cards, comments and checklists are never cached, so they are always current.
Tags, custom field definitions, groups and webhooks are not exposed, and nothing writes to Favro. Open an issue if you need something added.
npm install
npm test
npm run buildInspect the server interactively against your real account:
FAVRO_EMAIL=you@example.com FAVRO_API_TOKEN=your-token npx @modelcontextprotocol/inspector node dist/index.jsMIT
Get a single Favro board (widget) by its widgetCommonId, including its lanes and columns. This is the cheapest way to learn a board's column layout before listing cards. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. | |
| widgetCommonId | Yes | The widgetCommonId of the board to retrieve, as returned by list-boards. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by disclosing it's 'cheapest' (cost implication) and 'results are cached'. Annotations already indicate safe read and open world, but description enriches with performance 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?
Two sentences, front-loaded with action and resource, no filler. Every sentence adds value: purpose, cheapest way, caching. Excellent conciseness.
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, description explains what is returned (lanes and columns). Also provides caching and cost context. For a simple read tool with robust annotations, this is fully adequate.
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 does not add new meaning to parameters beyond schema descriptions; it only mentions output content (lanes and columns). No need to compensate.
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 clearly states verb 'Get', resource 'single Favro board', identifier 'widgetCommonId', and includes details about lanes and columns. Distinguishes from siblings like list-boards and list-columns by positioning it as the cheapest way to get column layout.
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 'cheapest way to learn a board's column layout before listing cards', guiding agents to use this when needing column layout prior to list-cards. Also mentions caching. However, lacks explicit exclusions or alternatives beyond the implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Favro card by its cardId, with the full untruncated description plus custom fields, dependencies, attachments, and time-on-board data. Use the cardCommonId from the result to fetch the card's comments and checklists. Not cached, so results are always current.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The cardId of the card to retrieve. This is the per-board id, not the cardCommonId. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. | |
| descriptionFormat | No | Format of the card description. Use "markdown" to preserve formatting. Defaults to "plaintext". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by noting results are not cached and always current. Also implies completeness ('full untruncated description') which is useful. No contradictions with readOnlyHint and openWorldHint.
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 dense sentences: first covers purpose and inclusions, second gives post-usage guidance and caching info. No filler words, front-loaded with key 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?
With no output schema, description lists included data fields (description, custom fields, dependencies, attachments, time-on-board), which is helpful. Could mention other common fields like title/status, but sufficient for typical 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?
Although schema coverage is 100%, description clarifies cardId as 'per-board id, not the cardCommonId' and hints at result field cardCommonId. Also explains usage of descriptionFormat enum. Adds meaningful context 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?
Description explicitly states 'Get one Favro card by its cardId' and lists included data (full untruncated description, custom fields, dependencies, attachments, time-on-board data). Differentiates from sibling tools like list-cards and search-cards by specifying singular retrieval and completeness.
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 clear next-step guidance: 'Use the cardCommonId from the result to fetch the card's comments and checklists.' Also states caching behavior ('Not cached, so results are always current'). However, does not explicitly state when to avoid this tool or compare directly with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Favro collection by id, including its sharing level and archived state. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The id of the collection to retrieve. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, indicating a safe read operation. The description adds the behavioral trait 'Results are cached' and specifies what the response includes (sharing level, archived state), providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the core purpose, and the second adds a useful behavioral note. Every word 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?
Given the low complexity (single object retrieval) and absence of an output schema, the description adequately covers the return content (sharing level, archived state). It could mention error handling or null returns, but overall it is sufficiently 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 description coverage is 100%, so the parameters are already well-documented. The description does not add new meaning beyond what the schema provides (e.g., 'collectionId' described as 'The id of the collection to retrieve'). Baseline 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 ('Get'), the resource ('a single Favro collection'), and the identifier ('by id'). It adds specific details about the data included (sharing level, archived state), and distinguishes from the sibling 'list-collections' which retrieves multiple collections.
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 usage context: use this when you need a specific collection by id, as opposed to 'list-collections' for browsing. However, it does not explicitly state when not to use it or provide alternatives, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a single Favro user by id. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The id of the user to retrieve. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds 'Results are cached,' which is a key behavioral trait not captured by annotations, guiding the agent on data freshness expectations.
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, front-loaded with the core purpose, no unnecessary 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?
The description lacks information about the return value format, which is not provided by an output schema, leaving the agent uncertain about what fields appear in the result.
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%, and the description does not add meaning beyond parameter descriptions; results caching is unrelated to parameter semantics.
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 'look up' and clearly identifies the resource as a single Favro user by id, distinguishing it from list-users which returns multiple users.
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 use when you have a specific user id, but does not explicitly state when to use this tool versus siblings like list-users, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Favro boards and backlogs, optionally filtered to one collection. The Favro API calls these "widgets", and each is identified by a widgetCommonId that other tools take. Type "board" is a Kanban board, type "backlog" is a card list. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| archived | No | Return archived boards instead of active ones. Defaults to false. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| collectionId | No | Only return boards that belong to this collection. Omit to list every board shared with the account. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. Description adds value: notes caching behavior, explains pagination indirectly via schema, and clarifies API naming. No destructive actions implied.
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 sentences, no waste. Front-loaded with main purpose, each sentence adds distinct value (purpose, API explanation, behavior note).
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?
Without an output schema, the description explains what the tool does, mentions caching, and clarifies API context. Sufficient for agent understanding, though could briefly describe return structure.
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% with all parameters described. The description adds minor context (optional filter by collection, pagination hints) but does not significantly enhance meaning 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 'List Favro boards and backlogs' with specific verb and resource. It distinguishes by mentioning optional collection filter and explains API terminology ('widgets', widgetCommonId).
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 clear context for usage (list boards/backlogs, filter by collection) and mentions caching. Does not explicitly state when not to use, but sibling tools are listed for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the comments on a Favro card. Takes the card's cardCommonId, not its cardId, because comments are shared across every instance of the card. Use list-users to turn the returned userIds into names. Not cached, so results are always current.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| cardCommonId | Yes | The cardCommonId of the card whose comments should be read, as returned by get-card or list-cards. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with readOnlyHint and openWorldHint annotations, and adds valuable behavioral info ('Not cached', cardCommonId detail) that goes beyond annotations.
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, front-loaded with core purpose, no filler. Every 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?
Covers key aspects: identifier choice, pagination hints, post-processing from output. Lacks explicit output structure details, but given lack of output schema, it is reasonably 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% with good parameter descriptions; the description reinforces cardCommonId usage but adds little extra meaning for parameters 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?
Clearly states it reads comments on a Favro card, specifies the required identifier (cardCommonId), and distinguishes from card-related siblings by focusing on comments.
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?
Explains why to use cardCommonId instead of cardId, advises using list-users for post-processing, and notes that results are uncached. Lacks explicit exclusions or when-not-to-use, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Favro cards on a board, in a collection, or in the account's todo list. You must scope the call with one of widgetCommonId, collectionId, cardCommonId, cardSequentialId, or todoList. columnId narrows the results further but cannot be used on its own. Card descriptions are truncated here; use get-card for the full text. Not cached, so results are always current.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| unique | No | Return each card only once even when it appears on several boards. Defaults to false. | |
| archived | No | Return archived cards instead of active ones. Defaults to false. | |
| columnId | No | Narrow the results to a single column. Must be combined with widgetCommonId. | |
| todoList | No | Return cards from the authenticated user's todo list. One of the accepted scopes. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| cardCommonId | No | Return every instance of this card across boards. One of the accepted scopes. | |
| collectionId | No | Return cards in this collection. One of the accepted scopes. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. | |
| widgetCommonId | No | Return cards on this board. One of the accepted scopes. | |
| cardSequentialId | No | Return the card with this human-readable sequential id. One of the accepted scopes. | |
| descriptionFormat | No | Format of the card description. Defaults to "plaintext". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and openWorldHint. Description adds 'Not cached, so results are always current' and truncation behavior, providing context beyond annotations without contradiction.
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 concise sentences front-loading purpose, then constraints, then behavioral notes. No fluff or repetition.
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 scoping, truncation, and caching. Lacks mention of return structure or pagination details, but given no output schema and annotations present, the description is mostly adequate.
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 relationships (e.g., columnId must be combined with widgetCommonId) and scoping rules, enhancing understanding beyond the schema alone.
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 Favro cards on a board, collection, or todo list, with a specific verb and resource. It distinguishes from siblings like get-card and search-cards by mentioning truncation and scoping.
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 states required scoping parameters and that columnId cannot be used alone. Mentions that descriptions are truncated and get-card should be used for full text, providing clear when-to-use and when-not-to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the checklists on a Favro card. The Favro API calls these "tasklists". Takes the card's cardCommonId. Pass a returned taskListId to list-card-tasks to read the items in one checklist. Not cached, so results are always current.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| cardCommonId | Yes | The cardCommonId of the card whose checklists should be listed. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with a read operation. The description adds 'Not cached, so results are always current,' providing extra behavioral insight beyond annotations.
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 efficient sentences that front-load the core purpose and include essential usage guidance without any 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?
The description explains the tool's context (listing checklists, not tasks), notes the current results, and connects to the sibling tool. Lacks return format details, but acceptable for a list operation given well-documented parameters.
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 description adds little beyond what the schema provides. The mention of cardCommonId reinforces but does not enrich the schema's documentation.
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 checklists/tasklists on a Favro card, specifies the required parameter cardCommonId, and distinguishes it from the sibling list-card-tasks tool.
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 clear context for use (listing checklists) and explicitly instructs to pass the returned taskListId to list-card-tasks for items, though it does not discuss when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the checklist items on a Favro card, with their completed state. The Favro API calls these "tasks". Takes the card's cardCommonId, and optionally a taskListId to read a single checklist. Not cached, so results are always current.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| taskListId | No | Only return items from this checklist, as returned by list-card-tasklists. | |
| cardCommonId | Yes | The cardCommonId of the card whose checklist items should be listed. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds that results are not cached, providing extra transparency about freshness. No contradictions.
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 sentences, front-loaded with the action, no wasted words. Every sentence provides 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?
Given 6 parameters and no output schema, description covers the core purpose, optional filtering, and caching. Pagination is documented in schema, so not needed in description. Completeness is good.
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%. Description mentions the key parameters (cardCommonId, taskListId) but does not add significant meaning beyond the schema. Baseline 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?
Description clearly states it lists checklist items on a Favro card, including the completed state. It specifies the required cardCommonId and optional taskListId. This distinguishes it from sibling tools like list-card-tasklists.
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 (to list checklist items) and mentions optional filtering by taskListId. No explicit exclusions, but the purpose is clear enough to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Favro collections shared with the account. A collection groups related boards and backlogs, so this is the usual entry point for exploring an organization. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| archived | No | Return archived collections instead of active ones. Defaults to false. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world. The description adds that 'Results are cached', which is useful behavioral context but not extensive. No contradictory information is present.
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, each carrying essential information: what the tool does, what a collection is, its place in exploration, and caching behavior. No fluff or 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?
Given the simplicity of a list tool with pagination and annotations present, the description covers key aspects but lacks mention of the return structure or pagination details, which the schema partially covers. Adequate but not fully 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?
All 5 parameters have schema descriptions, so the tool description does not need to add parameter-level detail. Baseline 3 is appropriate as it offers no extra meaning beyond the schema's own 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 it lists Favro collections and explains what a collection represents, calling it 'the usual entry point'. This gives strong purpose clarity, but it does not explicitly differentiate from sibling list tools like list-boards or list-organizations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the first step for exploration ('usual entry point'), but it does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or context switching advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the columns on a Favro board, with each column's position and card count. Use the returned columnId to narrow list-cards to a single column. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. | |
| widgetCommonId | Yes | The widgetCommonId of the board whose columns should be listed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that results are cached, which is a non-obvious behavioral trait not covered by annotations. No contradictions.
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 sentences with zero wasted words. Purpose, return value, usage hint, and caching behavior are all front-loaded and precise.
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 parameters fully described in schema) and no output schema, the description adequately covers return values (position, card count) and caching. It doesn't re-explain pagination since the schema covers it, and the open world hint is already in annotations. Minor gap: no mention of the optional parameters' role, but schema handles that.
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 fully documents all 5 parameters. The description does not add parameter-specific semantics beyond the schema, but the mention of output fields (position, card count) provides context for interpreting the results, justifying a baseline score of 3.
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 clearly states the tool lists columns on a Favro board, specifies return fields (position and card count), and explains the primary use case (using columnId to filter list-cards). This fully distinguishes it from sibling tools like list-boards.
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 context: use the returned columnId to narrow list-cards to a single column. While it doesn't explicitly state when not to use it, the guidance is clear enough that an agent can infer alternatives (e.g., list-boards for boards).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Favro organizations the configured account belongs to. Start here when no organization is configured, then pass the organizationId to other tools. This route is limited to 50 calls per hour, so results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds important context: a 50-calls-per-hour rate limit and result caching. This goes beyond the annotations to inform the agent of constraints and performance characteristics.
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 efficient sentences: purpose, usage guidance, and behavioral note. No wasted words; the most critical 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?
For a simple list tool with pagination parameters and no output schema, the description covers purpose, usage flow, and rate limits. While it could mention the return format (list of organizations), the combination of clear schema and sufficient description makes it adequate.
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% with detailed parameter descriptions. The description does not add new parameter-level information beyond what the schema already provides, so the 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 'List the Favro organizations' with a specific verb and resource. It distinguishes itself from siblings by positioning as the entry point when no organization is configured, and it explains how the result (organizationId) feeds into other 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?
Explicit guidance: 'Start here when no organization is configured, then pass the organizationId to other tools.' While it doesn't explicitly list exclusions or alternatives, the context makes it clear that this is the first step for other tools requiring an organization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the users in a Favro organization, with their id, name, email, and role. Use this to resolve the userIds returned on card assignments and comments. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index. Omit for the first page. Favro returns 100 entities per page. | |
| backendId | No | Required when page is greater than 0: the backendId from the previous call's "pagination" block, which routes the request to the same Favro server. | |
| requestId | No | Required when page is greater than 0: the requestId from the previous call's "pagination" block. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral note that results are cached, beyond the annotations (readOnlyHint, openWorldHint). Pagination behavior is not described but is fully covered in the schema, so no contradiction. The caching info is valuable for agent understanding.
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, extremely concise, front-loaded with the action and result. Every sentence adds value: purpose, use case, caching behavior.
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 is complete for a simple read-only list tool. It covers purpose, return fields, and caching. Pagination is documented in schema. No output schema exists, but the description implies a list structure. Minor gap: does not explicitly state that the result is a list of user objects, but it's clear from context.
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?
All parameters have schema descriptions (100% coverage), so the description adds no new parameter-level meaning. It mentions organizationId defaults to the configured org, which is also in the schema. Baseline 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 tool lists users in a Favro organization and specifies the returned fields (id, name, email, role). It also provides a specific use case (resolving userIds from card assignments/comments), which distinguishes it from the sibling get-user tool.
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 resolve userIds from card assignments and comments, giving clear context. However, it does not mention when not to use it (e.g., for a single user, get-user might be more appropriate), but the sibling distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Favro cards whose name or description contains a piece of text. The Favro API has no card search, so this reads the cards on a board or in a collection and filters them here. Scope it with widgetCommonId or collectionId. Each 100 cards scanned costs one API call, so the scan stops after maxPages pages and reports whether it was cut short.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to look for in each card's name and description. Matching is case-insensitive substring matching, not full-text search. | |
| archived | No | Search archived cards instead of active ones. Defaults to false. | |
| columnId | No | Narrow the search to a single column of the board. | |
| maxPages | No | How many 100-card pages to read, each costing one API call. Defaults to 3, maximum 10. | |
| collectionId | No | Search the cards in this collection. Required unless widgetCommonId is given. | |
| organizationId | No | The Favro organization to query. Defaults to the organization configured for this MCP server. Use list-organizations to discover available ids. | |
| widgetCommonId | No | Search the cards on this board. Required unless collectionId is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds important behavioral details: it reads all cards and filters locally, each 100 cards costs one API call, stops after maxPages, and reports if cut short. This fully discloses the operational characteristics beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each delivering essential information: what the tool does, its limitation, scoping, and pagination cost. No wasted words; front-loaded with the primary 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?
Given the tool's complexity (search with pagination, cost, and cut-off), the description covers the main aspects: API limitation, scoping, pagination, and reporting cutoff. It lacks explicit mention of what the result contains (e.g., card IDs, full objects), but the absence of an output schema and the mention of 'reports whether it was cut short' partially compensates.
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 value by explaining the scoping requirement (widgetCommonId or collectionId) and the meaning of maxPages in terms of cost and cutoff. This contextual information helps the agent use parameters correctly.
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 finds Favro cards by text in name or description, distinguishing it from list-cards (which lists without filtering) and get-card (single card). It also explains the limitation of the Favro API, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (to search cards by text) and how to scope it (with widgetCommonId or collectionId). It explains the cost per page and pagination behavior. While it doesn't explicitly list alternatives, it implies that list-cards is for unfiltered listing. Could be more precise about mutual exclusivity of parameters.
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.
v1.0.0get-boardget-cardget-collectionget-userlist-boardslist-card-commentslist-card-tasklistslist-card-taskslist-cardslist-collectionslist-columnslist-organizationslist-userssearch-cardsScored across 14 tools
Every tool targets a distinct resource and action, with clear boundaries between listing, getting, and searching. Even tools like list-cards and search-cards are differentiated by scoping and behavior.
All tools follow a consistent verb_noun pattern using either 'list-' for collections or 'get-' for single entities, making the naming predictable and easy to understand.
14 tools is a well-scoped set for a project management API, covering all major resource types without being bloated or sparse.
The tool set is entirely read-only, lacking any create, update, or delete operations for cards, boards, comments, etc. This is a significant gap for typical workflow automation, severely limiting the server's utility.
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Read-only MCP server exposing a user ORANO library to their own AI agent.
