Give your AI agent 75+ business tools: tasks, projects, CRM, forms, E-Sign, team comms, automations.
Scored across 8 tools
Each tool targets a distinct action: account listing, content search, record fetch, tool search, schema fetch, module listing, help, and tool execution. The discovery cluster (raq_search_tools, raq_get_tool_schema, raq_list_available_modules) has some conceptual proximity, but cross-references in the descriptions (e.g. 'to find tools rather than records, use raq_search_tools') keep them separable. Only mild overlap risk remains between tool-search and module-listing.
Seven of eight tools follow a consistent raq_ verb_noun pattern (raq_search, raq_fetch, raq_get_tool_schema, etc.), which is predictable and readable. list_accounts deviates by omitting the raq_ prefix, a minor inconsistency but the only one.
Eight tools is well within the well-scoped range and is intentional for a lean gateway that defers the large catalogue to progressive disclosure. Each tool (account listing, search, fetch, schema, modules, help, execution) earns its place. Slightly over-minimal due to three separate discovery tools rather than a single one.
The surface covers the full gateway lifecycle: discover accounts, discover tools/modules, fetch schemas, search content, read records, invoke tools, and get help. Underlying domain operations (create/update/delete across the many Raq modules) are handled through raq_call_tool, so coverage is effectively broad. A minor gap is that records can only be opened via a raq_search result id, with no direct read-by-id path.
Lists the accounts available to this connection. Returns account IDs,
names, slugs, and roles, plus the authenticated user profile for this
MCP connection. If only one account is available, it is used
automatically for all tool calls. If multiple are available, pass
`account_id` to target a specific one.| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavior beyond that: it lists the returned fields and explains the automatic single-account behavior versus the multi-account targeting requirement.
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 front-loaded sentences with little waste. The final sentence about account_id is useful but slightly ambiguous because it refers to a parameter that this tool does not accept.
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, the description appropriately lists the return values and explains account-selection behavior. It is nearly complete for a zero-parameter read tool, with only minor ambiguity around the account_id reference.
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 zero parameters, so the schema baseline is 4. The description mentions account_id for targeting when multiple accounts exist, but because account_id is not a parameter of this tool, that reference is slightly ambiguous rather than schema-documenting.
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 a specific verb and resource: it lists accounts available to this connection and names the returned fields (IDs, names, slugs, roles, user profile). It is clear, though it does not explicitly differentiate itself from the generic raq_* 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?
It gives clear usage context: a single available account is used automatically, while multiple accounts require passing account_id to target one. It does not describe when not to use this tool or name an alternative, but the selection guidance is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call one authorised Raq.com MCP tool by exact tool name. This is the
progressive gateway for the lean agent endpoint: keep the large tool
catalogue out of context, fetch a schema when needed, then call the
selected tool here.| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | Arguments for the target tool. Use raq_get_tool_schema if unsure. For external_mcp_call_tool, pass the external tool inputs inside arguments.arguments, not tool_input. | |
| tool_name | Yes | Exact MCP tool name to call, for example task_board_list_boards. | |
| account_id | No | Default account ID to inject when arguments.account_id is omitted. | |
| allow_broad_response | No | Only set true after confirming a broad nested response is required. The lean response budget still applies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden. It discloses that only 'authorised' tools can be called and that a lean response budget applies, plus gates broad nested responses behind allow_broad_response. However, since this proxy can invoke any tool including mutating ones, the absence of any statement about side effects, reversibility, or error behavior is a meaningful gap.
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 short sentences with no filler, and the core action plus the exact-name requirement are front-loaded. The leading whitespace and quoted wrapping are cosmetic noise rather than a structural problem.
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 four-parameter proxy with a nested arguments object, no annotations, and no output schema, the description explains the workflow well but never indicates what the caller receives back (presumably the target tool's result, possibly trimmed by the lean budget). An agent must infer the return contract and failure modes.
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 every parameter is already documented in the schema, including the nested arguments object and its guidance to consult raq_get_tool_schema. The description only reinforces the 'exact tool name' requirement and adds no format or example detail beyond the schema's own task_board_list_boards example.
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 names a specific verb and resource: 'Call one authorised Raq.com MCP tool by exact tool name'. It also frames the tool's role as a progressive gateway that reaches a large catalogue indirectly, which separates it from simple lookup tools like raq_search_tools without naming them directly.
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?
It gives a clear workflow — keep the catalogue out of context, fetch a schema when needed, then invoke the selected tool here — which implicitly routes the agent to raq_get_tool_schema first when the inputs are unknown. It stops short of explicit exclusions or stating what to do when the named tool is not available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one raq_search result in full as plain text, with its URL, dates
and the module tool that edits it (native_tool). Long records come in
windows: follow next_offset, or pass around with words from the
search snippet to open the record at that passage.| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Result id from raq_search, e.g. "task_card:019c...". | |
| around | No | Words to open the text at, usually copied from the search snippet. Overrides offset. | |
| offset | No | Character offset to start reading from. Default 0. | |
| max_chars | No | Characters to return. Default 8000, max 40000. | |
| account_id | No | Account ID. Omit to use your default account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered; the description adds genuinely new behavior: output is plain text, includes URL/dates/editing tool, and long records are returned in character windows paginated by next_offset. It stops short of documenting truncation/error behavior or limits beyond the schema's max_chars.
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 tight sentences, front-loaded with what is returned, then the pagination workflow. No filler and no restatement of the title.
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, the description carries the return-value burden and does so by naming the text, URL, dates, native_tool and next_offset. The main remaining gap is failure modes (invalid or outdated id) and how the windowing interacts with max_chars.
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 each parameter including around's override of offset is already documented. The description reinforces the around/offset workflow with snippet words and introduces next_offset as the continuation signal, but adds little semantics the schema does not already carry.
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?
States a specific verb and resource (read one raq_search result in full as plain text) and names the return payload (URL, dates, native_tool). It also anchors itself to siblings by tying input to raq_search and pointing edits at the module tool, so an agent can distinguish it from raq_search and raq_call_tool immediately.
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?
Clear context: use this after raq_search to expand a single result, and use native_tool to edit it rather than this reader. Explicit instructions for long records (follow next_offset, or use around with snippet words) make the when-and-how concrete, though it never states what to do if the id is stale or not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raq.com help and support for agents. Ask a how-to question (where things are in the app, adding modules, connecting agents, designing documents, files, roles, credits, getting human help) or pass a module slug for what that module is for and whether this account has it. Answer the user from this instead of guessing Raq.com navigation.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Exact topic title from a previous raq_get_help response. | |
| module | No | Module slug, for example "design-mcp", to explain that module. | |
| question | No | How-to question or keywords, for example "how do I add a module to my sidebar". | |
| account_id | No | Account ID. Omit to use your default account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint, so the description carries the rest, and it does disclose that responses are account-scoped ("whether this account has it") and that the tool is a grounding source rather than a guess. It does not describe response shape or how the topic follow-up flow behaves, but the mode split and account scoping go meaningfully beyond the annotation.
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 two operating modes are front-loaded in the first sentence and the behavioral directive closes it, with no filler. The opening fragment "Raq.com help and support for agents." is slightly redundant with the title and name, but the rest is dense and useful.
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?
Four optional parameters with no required ones means the agent must decide which combination to send, and the description does not explain how question, module, and topic relate or which takes precedence. With no output schema and a mention that `topic` comes from a prior response, the multi-turn flow is left implicit.
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 the baseline is 3. The description does gloss two of the params (question, module) in intent terms and hints at a chained flow via module slug lookup, but it says nothing about `topic` or `account_id` that the schema does not already provide.
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 names a specific resource (Raq.com help/support) and two concrete modes: answer a how-to question, or explain a module slug including whether the account has it. That is clearly distinct from data-fetching siblings like raq_fetch or raq_search, though it never explicitly contrasts itself with raq_list_available_modules, which overlaps the module-availability claim.
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?
It gives explicit triggering context ("Ask a how-to question... or pass a module slug") and a directive on how to use the result ("Answer the user from this instead of guessing Raq.com navigation"). It stops short of naming when to prefer a sibling such as raq_list_available_modules for module discovery or raq_search for content lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full schema and description for one authorised Raq.com MCP
tool. Use this only after choosing a likely tool from instructions,
raq_search_tools, or a direct tool name supplied by the user.
Supply account_id to check account prerequisites. Unavailable tools
return permission-safe access diagnostics, not evidence of missing data.| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Exact MCP tool name, for example task_board_list_boards. | |
| account_id | No | Account to check for access prerequisites. Omit for the normal schema lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description does add non-obvious failure semantics ('Unavailable tools return permission-safe access diagnostics, not evidence of missing data') and scoping to 'authorised' tools, but it never describes the shape of a successful response or what the schema payload contains.
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 short sentences, each carrying distinct information: what it fetches, when to use it, and what happens on failure. Nothing is repeated and the core purpose 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?
With no output schema, the description does explain the payload at a high level (full schema and description) and covers the error path, which is adequate for a simple two-parameter read tool. It stops short of saying how the returned schema should then be used with raq_call_tool, a minor gap given the sibling set.
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 both parameters are already documented in the input schema, including the account_id prerequisite-check meaning. The description restates rather than extends that meaning, so the baseline 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?
The description gives a specific verb and resource ('Fetch the full schema and description for one authorised Raq.com MCP tool') and implicitly separates it from sibling retrieval tools like raq_search_tools and raq_call_tool by framing it as a single-tool schema lookup.
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?
It states an explicit precondition ('Use this only after choosing a likely tool from instructions, raq_search_tools, or a direct tool name supplied by the user'), naming the alternative that precedes it, and adds a distinct secondary use for account_id (prerequisite checking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the main Raq.com modules enabled for the selected account. Use
this to refresh the compact module catalogue shown in the lean agent
endpoint instructions without loading every individual tool schema.
Pass include_not_enabled true to also list modules the account has not
added yet, which enable_module can add.| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Account ID. Omit to use your default account. | |
| include_not_enabled | No | Also list modules not yet added to the account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety. The description adds useful behavioral context: it returns a compact catalogue rather than full schemas, and include_not_enabled expands results to modules not yet added. It does not describe return ordering or pagination, but for a simple read-only listing this is reasonable.
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 tight sentences, front-loaded with the core purpose and followed by the key usage detail and parameter behavior. Every sentence contributes to selecting or invoking the tool correctly.
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 two-parameter read-only listing tool with full schema coverage and no output schema, the description is nearly complete. It could mention the return shape or ordering, but the core behavior and optional expansion are clearly conveyed.
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 both parameters are already documented. The description adds some meaning by explaining that include_not_enabled reveals modules that enable_module can add, but it largely restates the schema's parameter 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 states a specific verb and resource: it lists the main Raq.com modules enabled for the selected account. It also clarifies the scope by mentioning the compact module catalogue rather than individual tool schemas, which distinguishes it from schema-fetching siblings.
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?
It gives clear usage context: use this to refresh the compact module catalogue without loading every individual tool schema. It also explains the include_not_enabled option and its relationship to enable_module. It does not explicitly state when not to use it or name a specific alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the content of everything you can read in this Raq.com account in one call. Results are ranked across modules, each with an id, URL, dates and a snippet of the matching passage. Read a result in full with raq_fetch. To find tools rather than records, use raq_search_tools.
Query syntax: plain words (ranked by how many match), "exact phrase",
+required, -excluded. Prefer several short, specific searches to one
long question; names, IDs and email addresses work well. coverage
lists modules that were not searched and why, so a missing result is
not proof that something does not exist.Searchable module slugs: company-knowledge, projects, task-board, crm, help-desk, team-comms, multi-model-chat, file-drop, onedrive-search, transcribe, pretty-docs, co-write, quotes-proposals, invoice-generator, e-sign, time-tracker, bookings, form-builder, receipt-extractor, client-portal, priorities, skill-library, agent-audit, data-cleanup, agent-brain, prompt-library, personas, automations, market-intel, contract-auditor, ai-pro-reasoning, social-scheduler, rewriter, ghostwriter, anti-slop-writer, support-chatbot, ask-my-agent, voice-calls, journal, recall.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page. Default 10, max 25. | |
| match | No | "any" (default) ranks records by how many words match; "all" requires every word. | |
| query | Yes | Words to find, e.g. acme renewal or "payment terms" -draft. | |
| types | No | Result types to keep, e.g. ["task_card"]. Omit to keep all. | |
| cursor | No | next_cursor from the previous page of the same search. | |
| modules | No | Module slugs to search, e.g. ["crm", "task-board"]. Omit to search every module. | |
| account_id | No | Account ID. Omit to use your default account. | |
| updated_after | No | Only records updated on or after this ISO 8601 date or time. | |
| updated_before | No | Only records updated before this ISO 8601 date or time. | |
| response_format | No | "concise" (default) or "detailed", which adds authors, full timestamps, matched terms and per-module coverage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and idempotentHint, so the description must carry the rest — and it does: cross-module ranking, the shape of each result (id, URL, dates, matching snippet rather than full content), and the partial-coverage caveat that explains why results may be incomplete. This is disclosure an agent cannot get from the annotations or schema.
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?
Front-loaded with purpose and routing before syntax details, and every sentence carries information. The 40-item module slug list is bulky and visually dominates the block, though it is genuinely necessary for the untyped 'modules' array.
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 10-parameter cross-module search with no output schema, the description covers routing, query syntax, result shape, and the coverage caveat, while pagination, date filters and response_format are fully documented in the schema. Nothing an agent needs to call this correctly is missing.
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 already 100%, so the baseline is 3, but the description adds query-language semantics absent from the schema: plain words ranked by match count, "exact phrase", +required, -excluded. It also enumerates the valid module slugs for the 'modules' array, which the schema does not constrain. It does not explain cursor paging or the limit ceiling beyond what the schema already says.
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?
Opens with a specific verb and scope: 'Search the content of everything you can read in this Raq.com account in one call', plus states results are ranked across modules with id, URL, dates and a snippet. It explicitly distinguishes itself from both siblings by routing full-record reads to raq_fetch and tool discovery to raq_search_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?
Gives explicit alternatives with the condition that selects each ('Read a result in full with raq_fetch'; 'To find tools rather than records, use raq_search_tools'), and adds strategic advice to prefer several short specific searches over one long question. It also warns that 'coverage lists modules that were not searched and why, so a missing result is not proof that something does not exist', which prevents a common false-negative conclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the full authorised Raq.com MCP tool catalogue by task, module,
or direct tool name. Returns compact matches only. Call
raq_get_tool_schema for the selected tool, then use the gateway named
in its call_with response.
Matching modules the account has not added yet are returned under
modules_not_enabled; add one with enable_module if the user wants it.
An empty result means no authorised tools matched, not that the account
has no records. Check a known tool with raq_get_tool_schema and account_id
for access diagnostics.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return. Default 12, max 50. | |
| query | Yes | Search text, for example "task board cards", "crm leads", or "pretty docs". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real value on top by disclosing the compact return shape, the existence of the modules_not_enabled bucket, and that empty results mean no authorised tools matched rather than no account data. It stops short of describing match ordering or relevance behavior, but the operational semantics an agent needs are 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?
The core capability and the follow-up workflow are front-loaded in the first two sentences, followed by edge-case handling for modules_not_enabled and empty results. Every sentence carries operational information; there is no restatement of the title or padding.
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 two-parameter discovery tool with no output schema, the description covers the call sequence, the return shape, the enable-module escape hatch, and the failure semantics of an empty result. An agent has everything needed to call it and act on the response without further guessing.
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 both query and limit are already documented in the schema, including examples and the default/max for limit. The description adds only the 'by task, module, or direct tool name' framing for query, which is a modest increment over the schema's own examples, so this sits at the baseline.
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 opening sentence names a specific verb and resource ('Search the full authorised Raq.com MCP tool catalogue') and scopes it to three matching modes: task, module, or direct tool name. It implies the distinction from raq_get_tool_schema by naming that tool as the follow-up step, but never explicitly contrasts itself with the sibling raq_search, so an agent must infer the boundary.
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?
It prescribes an explicit two-step workflow: call raq_get_tool_schema for the selected tool, then use the gateway named in its call_with response. It also states what to do with modules_not_enabled (enable_module) and how to interpret an empty result, including the fallback diagnostic path through raq_get_tool_schema with account_id.
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.
list_accountsraq_call_toolraq_fetchraq_get_helpraq_get_tool_schemaraq_list_available_modulesraq_searchraq_search_toolsBuild and run agents and automations across hundreds of apps using natural language.
AI-native project management for tasks, docs, collaboration, and agents.
Projects, tasks, chat and docs for a team and its AI agents, at one flat price.
Work in QuiQSol from any AI agent: CRM, Help Desk, inbox, invoices, projects, forms and analytics.
Add one secure layer between your agents and this server.
