Signal Found MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
There is significant functional overlap between tools, causing ambiguity. For example, 'crm_workbench' includes actions like 'get_conversation_by_id' and 'update_conversion_state', which duplicate standalone tools 'get_conversation_by_id' and 'change_crm_state'. Similarly, 'modify_conversion_notes' and 'update_conversation_notes'/ 'upsert_conversation_note' have overlapping purposes. However, detailed descriptions help differentiate some tools.
Naming Consistency4/5
Most tools follow a consistent snake_case verb_noun pattern (e.g., 'create_new_account', 'list_campaigns', 'modify_keywords'), which aids readability. Minor deviations exist, such as 'agent_quickstart' (noun_verb) and abbreviations like 'sf_health', but the overall convention is predictable and coherent.
Tool Count2/5
With 40 tools, the count is excessive for the apparent scope of customer onboarding, CRM management, and campaign operations. Many tools could be consolidated (e.g., overlapping CRM tools), leading to a bloated interface that may overwhelm agents and increase misselection risk.
Completeness5/5
The tool set provides comprehensive coverage for the domain, including full onboarding workflows (e.g., 'run_full_agentic_onboarding'), CRM operations (e.g., 'crm_workbench'), targeting configuration (e.g., 'modify_keywords'), campaign management (e.g., 'list_campaigns'), and analytics (e.g., 'portfolio_close_rate'). No obvious gaps are present; agents can perform end-to-end tasks without dead ends.
Average 3.4/5 across 40 of 40 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether this is a read-only or destructive operation, any authentication requirements, rate limits, or how the sampling is performed (e.g., random, recent). The description is too vague to inform the agent about the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function and output. It is front-loaded with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving sampling and comparison of conversation states), lack of annotations, and 0% schema coverage, the description is insufficient. While an output schema exists, the description doesn't address critical aspects like behavioral traits or parameter meanings, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description adds no information about parameters like 'product_slug', 'client_id', 'confirmed_count', or 'uninterested_count', leaving their purposes and effects completely unspecified. This is inadequate for a tool with multiple parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pull sample confirmed and uninterested conversations') and the output format ('return side-by-side message snippets'), which is specific and actionable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_conversation_by_id' or 'crm_customers_by_state', which might also involve conversation data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as 'get_conversation_by_id' for detailed single conversations or 'crm_state_stats' for aggregated data. It lacks context about prerequisites or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Read/update' but doesn't disclose behavioral traits such as required permissions, whether updates are partial or complete, if changes are reversible, rate limits, or response format. This leaves significant gaps for a tool that likely performs mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Read/update product strategy assets') and specifies the assets. There's no wasted text, though it could be more structured with separate clauses for purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It doesn't explain parameter meanings, behavioral context, or differentiation from siblings. The output schema may cover return values, but the description lacks crucial operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the assets handled ('market position, conversion notes, and funnels'), which loosely maps to some parameters, but doesn't explain their semantics, relationships, or how they interact. For 5 parameters with no schema descriptions, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool handles 'product strategy assets: market position, conversion notes, and funnels' with 'Read/update' operations, which provides a general purpose. However, it doesn't specify the exact verb (e.g., configure vs. modify) or clearly differentiate from siblings like 'modify_market_positioning', 'modify_conversion_notes', and 'modify_funnels', making it somewhat vague about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'modify_market_positioning', 'modify_conversion_notes', and 'modify_funnels' that handle specific assets, there's no indication of whether this tool is for bulk updates, initial configuration, or a different context, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Read/update' but doesn't clarify if this is a read-only, write-only, or combined operation, nor does it address permissions, side effects, rate limits, or response format. The description is too brief to provide meaningful behavioral context for an 8-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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, but its brevity leads to under-specification rather than true conciseness, as it omits necessary details for such a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain parameter interactions, usage scenarios, or behavioral traits, leaving significant gaps for an agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'subreddit targeting and keywords,' which loosely relates to parameters like 'subreddit_groups' and 'keywords,' but ignores others such as 'product_slug,' 'client_id,' and boolean flags like 'setup_subreddits.' This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Read/update subreddit targeting and keywords for a product,' which is clear but vague. It specifies the verb ('Read/update'), resource ('subreddit targeting and keywords'), and scope ('for a product'), but doesn't distinguish it from sibling tools like 'modify_keywords' or 'modify_subreddits,' leaving ambiguity about when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'modify_keywords' and 'modify_subreddits' available, it's unclear if this tool is for bulk operations, initial setup, or something else. No context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions two actions (getting overview and optionally creating checkout), but doesn't clarify if this is a read-only operation, whether it modifies data, what permissions are needed, or any rate limits. The optional checkout creation suggests potential side effects, but this isn't explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. However, it could be more structured—for example, separating the two functions more clearly. There's no wasted text, but it's somewhat terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations) and the presence of an output schema, the description is incomplete. It doesn't adequately cover parameter semantics or behavioral traits, though the output schema may help with return values. For a tool with billing and checkout functionality, more context on usage and effects is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 6 parameters. It only vaguely references 'optionally create a checkout session preview/action,' which relates to some parameters (like checkout_plan, success_url), but doesn't explain parameter meanings, relationships, or why certain defaults exist (e.g., history_limit default of 50). Most parameters remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get[s] billing + credits overview, and optionally create[s] a checkout session preview/action,' which provides a general purpose. However, it's vague about what 'billing + credits overview' entails and doesn't clearly distinguish this tool from potential siblings (none listed are billing-related, but the description lacks specificity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions an optional checkout preview/action, but doesn't explain when to include it or what scenarios warrant its use. There's no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' notes, implying a read-only operation, but does not clarify permissions, rate limits, error handling, or what the output contains. For a tool with no annotation coverage, this is a significant gap in transparency, as critical behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse. However, it could be more structured by including key details, but it earns high marks for brevity and clarity within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low parameter coverage, the description is minimally adequate. It covers the basic purpose but lacks details on usage, parameters, and behavioral context. For a tool with 3 parameters and no annotations, it should provide more guidance to be fully complete, but the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'product scope' and 'CRM conversation,' which loosely relates to 'product_slug' and 'conversation_id,' but does not explain their semantics, formats, or the optional 'client_id' parameter. It adds minimal value beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get notes for a CRM conversation in a product scope,' which clearly identifies the action (get) and resource (notes for a CRM conversation). However, it does not differentiate from sibling tools like 'get_conversation_by_id' or 'update_conversation_notes,' making the scope somewhat vague. It avoids tautology but lacks specificity about what 'notes' entail or how this differs from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention sibling tools such as 'get_conversation_by_id' (which might retrieve conversation details without notes) or 'update_conversation_notes' (for modifications), nor does it specify prerequisites or context for usage. This leaves the agent without explicit direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'read/write operations' which implies both querying and mutation capabilities, but doesn't specify authentication requirements, rate limits, error conditions, or what happens during write operations. The description adds some context about exclusions (messaging behaviors) but lacks critical behavioral details for a tool with 13 parameters and both read/write operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three short paragraphs and a bulleted list. It's front-loaded with the core purpose statement. The bulleted action list is well-structured. While efficient, the brevity comes at the cost of completeness for such a complex tool with 13 parameters and multiple operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, multiple operations, read/write capabilities), no annotations, and 0% schema description coverage, the description is inadequate. While an output schema exists (which helps with return values), the description fails to explain the relationship between actions and parameters, doesn't provide behavioral context for mutations, and offers minimal guidance for a tool that appears to be a multi-function CRM interface competing with several specialized sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While it lists supported actions and mentions that 'each action has its own required fields', it doesn't explain which parameters correspond to which actions or provide any semantic meaning for the 13 parameters. The description adds minimal value beyond what the bare schema provides, failing to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'CRM read/write operations' which provides a general purpose, but it's vague about the specific resource scope. It distinguishes from messaging behaviors by stating 'no reply generation and no DM sending', but doesn't clearly differentiate from sibling CRM tools like 'change_crm_state', 'crm_customers_by_state', or 'crm_state_stats'. The tool name 'crm_workbench' suggests a broader CRM interface, but the description lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by listing supported actions and stating what's excluded ('no reply generation and no DM sending'). However, it doesn't explicitly state when to use this tool versus the many sibling CRM tools (like 'change_crm_state', 'crm_customers_by_state', etc.). The instruction to 'Use `action` to select operation' is basic parameter guidance rather than contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get conversation messages,' which implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication needs, rate limits, pagination, error handling, or what the output contains. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action, making it easy to parse, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations) and the presence of an output schema (which likely covers return values), the description is minimally adequate but incomplete. It lacks details on parameter meanings, usage context, and behavioral aspects, making it insufficient for full understanding without relying heavily on the schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters (2 required), the description only vaguely references 'conversation ID' and 'product scope,' which partially maps to 'conversation_id' and 'product_slug' but doesn't explain their semantics, formats, or the optional 'client_id' parameter. It adds minimal value beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get conversation messages') and the target resource ('for a conversation ID inside a product scope'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_conversation_notes' or 'update_conversation_notes', which likely handle different aspects of conversations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, implying usage when you have a conversation ID and product scope, but it doesn't specify when to use this tool versus alternatives (e.g., 'get_conversation_notes' for notes instead of messages) or any prerequisites. No explicit when/when-not or alternative tools are mentioned, leaving the agent with little contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool lists campaigns with details like status and budget, but does not disclose critical behaviors such as whether it requires authentication, has rate limits, returns paginated results, or what happens if client_id is null. For a read operation with no annotation coverage, this leaves significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('List campaigns for a client') and adds relevant details. There is no wasted verbiage, and it is appropriately sized for the tool's complexity, though it could be more structured with bullet points or clearer formatting for the listed attributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low parameter coverage, the description is moderately complete. It covers the basic purpose and scope but lacks details on behavior, parameters, and usage context. For a simple list tool, it meets a minimum viable level but has clear gaps in transparency and guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (client_id) with 0% description coverage, and the description does not add any meaning beyond what the schema provides. It mentions 'for a client' but does not explain the semantics of client_id, such as its format, whether it's optional, or what happens if omitted. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('campaigns for a client'), specifying the scope includes active/inactive status, product mapping, budget, and warning signals. It distinguishes from siblings like 'list_products' or 'crm_customers_by_state' by focusing on campaigns, but does not explicitly differentiate from potential similar tools like 'portfolio_close_rate' or 'sales_control_tower' in terms of campaign listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions 'for a client' but does not specify prerequisites, exclusions, or compare to sibling tools like 'get_onboarding_status' or 'onboarding_campaign_decision' that might relate to campaigns. Usage is implied by the context of listing campaigns, but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to existing notes, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for what it communicates, though what it communicates is limited in scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations, 4 parameters with 0% schema coverage, but with an output schema present, the description is minimally adequate. The presence of an output schema means the description doesn't need to explain return values, but it should provide more context about the mutation behavior and parameter usage given the lack of annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description provides no additional semantic information about what 'product_slug', 'conversation_id', 'notes', or 'client_id' represent or how they should be used. The description mentions 'product scope' which relates to 'product_slug', but doesn't explain what format it expects or where to find valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update notes') and resource ('for a CRM conversation in a product scope'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'modify_conversion_notes' or 'upsert_conversation_note', which appear to have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'modify_conversion_notes' or 'upsert_conversation_note'. There's no mention of prerequisites, constraints, or appropriate contexts for selecting this specific update method over other similar tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool changes a CRM state, implying a mutation, but doesn't specify permissions required, whether changes are reversible, rate limits, or error handling. This leaves significant gaps for an agent to understand the tool's behavior safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and 0% schema coverage, the description is incomplete. It covers the basic purpose but lacks usage guidelines, detailed parameter explanations, and behavioral context needed for a mutation tool, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'product', 'customer', and 'category', which align with three parameters, but doesn't explain their semantics (e.g., what a 'product_slug' is, valid 'category' values, or the optional 'client_id' role). It adds minimal value beyond naming some parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the target ('customer's CRM conversion state (category) for a product'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_customers_by_state' or 'crm_state_stats', which might involve similar CRM state data but for different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like needing a valid customer or product, or contrast with tools like 'modify_conversion_notes' that might handle related data. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'explicit dedupe diagnostics,' which hints at output behavior, but fails to describe critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what 'dedupe diagnostics' entail. For a tool with 5 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. Every word earns its place by specifying listing, filtering, and diagnostics without redundancy. It avoids unnecessary elaboration while clearly stating the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, but with an output schema), the description is moderately complete. The output schema likely covers return values, reducing the need for output explanation in the description. However, the description lacks details on parameter usage, behavioral traits, and differentiation from siblings, leaving gaps that could hinder effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles provide minimal semantic context. The description adds no information about parameters beyond implying filtering by 'conversion states.' It doesn't explain what 'product_slug' refers to, the format of 'states', the purpose of 'client_id', or the meaning of 'include_conversations'. This fails to compensate for the poor schema coverage, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List CRM customer data filtered by conversion states with explicit dedupe diagnostics.' It specifies the verb ('List'), resource ('CRM customer data'), and key filtering criteria ('by conversion states'), distinguishing it from general listing tools. However, it doesn't explicitly differentiate from similar sibling tools like 'get_deduped_crm_by_category' or 'crm_state_stats', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, such as requiring 'product_slug' as the only mandatory parameter, or compare it to sibling tools like 'get_deduped_crm_by_category' for deduplication or 'crm_state_stats' for state-related analytics. This lack of context leaves the agent guessing about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what data is returned but doesn't cover important aspects like whether this is a read-only operation, if it requires specific permissions, potential rate limits, or how the 'unique deduped' logic works. The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that states the core purpose without any fluff. It's front-loaded with the essential information ('Return CRM state statistics') and uses the remainder to specify the aggregation method. Every word serves a purpose, making it maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and relatively simple parameters, the description covers the basic purpose adequately. However, with no annotations and 0% schema description coverage, it leaves significant gaps in understanding parameter meanings and behavioral constraints. For a statistical query tool, this is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all - not explaining what 'product_slug', 'client_id', or 'limit' mean in the context of CRM state statistics. While the output schema exists, the description fails to add any parameter context beyond what's minimally visible in the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and resource ('CRM state statistics'), specifying it provides 'unique deduped customer counts by conversion_state'. It distinguishes from siblings like 'crm_customers_by_state' by focusing on aggregated statistics rather than individual customer listings. However, it doesn't explicitly contrast with all potential alternatives like 'portfolio_close_rate' or 'get_deduped_crm_by_category'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose implies it's for statistical aggregation, there's no mention of when to choose it over similar tools like 'crm_customers_by_state' (which might list customers) or 'portfolio_close_rate' (which might provide different metrics). The description lacks any 'when' or 'when-not' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'deduped' records, implying duplicate removal, but doesn't disclose permissions needed, rate limits, pagination, or what 'deduped' entails (e.g., criteria, impact on data). For a retrieval tool with 5 parameters, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe returns) but no annotations and 5 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter meanings, and usage context, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'state or lead-category bucket' which loosely relates to the 'category' parameter, but doesn't explain any parameters (e.g., what 'product_slug' is, how 'include_conversations' affects output). With 5 undocumented parameters, this adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve deduped CRM records') and specifies the scope ('by single state or lead-category bucket'), which distinguishes it from general CRM retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'crm_customers_by_state' or 'crm_state_stats', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'single state or lead-category bucket' but doesn't explain when to choose this over other CRM tools like 'crm_customers_by_state' or 'crm_state_stats', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify permissions, rate limits, or what 'nested folders and products' entails structurally. The phrase 'equivalent to frontend product tree' adds some context about output format, but overall behavioral details are minimal for a tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using a single sentence that directly states the tool's purpose. The second part ('equivalent to frontend product tree') adds useful context without redundancy. However, it could be slightly more structured by explicitly mentioning the parameter or output, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to detail return values, which is adequate. However, with no annotations and low schema coverage, it lacks context on behavioral aspects like data retrieval constraints or client-specific nuances. The description is minimal but covers the core purpose, leaving gaps in usage and parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description adds no parameter-specific information. It mentions 'for a client', which aligns with the 'client_id' parameter, but doesn't explain its optionality (default null) or semantics. Since schema coverage is low, the description fails to compensate, resulting in a baseline score due to lack of added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get nested folders and products for a client', which specifies the verb ('Get'), resource ('folders and products'), and scope ('for a client'). It distinguishes from siblings like 'list_products' by emphasizing the nested structure. However, it doesn't explicitly differentiate from 'configure_product_strategy' or 'create_new_product', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions 'equivalent to frontend product tree', which hints at a UI representation but doesn't specify use cases, prerequisites, or exclusions. With siblings like 'list_products' and 'configure_product_strategy', the lack of comparative context leaves the agent guessing about appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('List') but doesn't disclose permissions needed, pagination, rate limits, or what happens when client_id is null. The output fields are listed but without explanation of their meaning or format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it could be more structured by separating parameter guidance from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), the description's minimalism is somewhat acceptable. However, for a tool with no annotations and 0% schema coverage, it lacks crucial context like authentication needs, error conditions, and parameter semantics, making it incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only partially does. It mentions 'for a client' which hints at the client_id parameter's role, but doesn't explain the parameter's purpose, format, or implications of the null default. The description lists output fields, which adds some context beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all products') and target resource ('for a client'), with specific output fields mentioned. It distinguishes from siblings like 'get_product_tree' by focusing on listing rather than hierarchical structure, though it doesn't explicitly contrast with all product-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_product_tree' or 'configure_product_strategy'. The description mentions 'for a client' but doesn't specify prerequisites, exclusions, or contextual triggers for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'compute' suggests a read-only operation, it doesn't clarify whether this requires specific permissions, what data sources it accesses, whether it performs real-time calculations or uses cached data, or what happens when client_id is null. The description lacks essential behavioral context for a tool that presumably accesses CRM data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for what it does convey, though it could benefit from additional context about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but no annotations and poor parameter documentation, the description is minimally adequate. It tells what the tool does at a high level but lacks crucial details about parameters, behavioral characteristics, and usage context that would make it complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only a parameter named 'client_id' and no documentation. The description provides no information about parameters whatsoever - it doesn't mention the client_id parameter, explain what it represents, or clarify when it should be used versus omitted. For a tool with one parameter and zero schema documentation, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compute' and the resource 'close rate across all products', specifying it's based on CRM conversion states. It distinguishes from siblings like 'crm_state_stats' by focusing on close rate calculation rather than general state statistics. However, it doesn't explicitly differentiate from all possible similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention when this tool is appropriate versus other CRM analysis tools like 'crm_state_stats' or 'compare_confirmed_vs_uninterested', nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'shift outbound/day budget,' implying a mutation operation, but fails to detail critical aspects like required permissions, whether the shift is reversible, potential side effects on campaigns, rate limits, or error conditions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It is front-loaded with the core purpose, making it easy to grasp quickly, and every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation implied, no annotations) and the presence of an output schema (which reduces the need to describe return values), the description is incomplete. It covers the basic purpose but lacks details on behavioral traits, parameter meanings, and usage context. However, the output schema helps mitigate some gaps, preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 8 parameters and 0% schema description coverage, the schema provides no descriptive context for parameters. The description only vaguely references 'worst active campaign' and 'target product campaign,' which partially relates to 'target_product_slug' but doesn't explain the meaning or usage of other parameters like 'lookback_days,' 'minimum_worst_outbound,' or date fields. It adds minimal value beyond the schema, insufficient to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Shift outbound/day budget') and the resources involved ('from the worst active campaign to a target product campaign'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'configure_product_strategy' or 'modify_keywords', which might also involve resource allocation or campaign adjustments, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other sibling tools like 'configure_product_strategy' or 'modify_funnels' that might handle similar budget adjustments. It lacks context on prerequisites, exclusions, or specific scenarios where this rebalancing is appropriate, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create/update' which implies mutation, but doesn't specify permissions needed, whether this overwrites existing notes or merges them, rate limits, error conditions, or what 'upsert' specifically means in this context. The description is too minimal for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's apparent complexity and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is minimally adequate. The output schema reduces the need to describe return values, but the description should still address behavioral aspects like how 'upsert' works, permissions, and parameter meanings. It meets the bare minimum but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no additional parameter semantics. It mentions 'product scope conversation' which hints at 'product_slug' and 'conversation_id', but doesn't explain what these identifiers represent, what format 'note' should take, or when 'client_id' is needed. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create/update') and target resource ('a conversation note for a product scope conversation'), providing specific verb+resource pairing. However, it doesn't distinguish this tool from sibling tools like 'update_conversation_notes' or 'modify_conversion_notes', leaving ambiguity about when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'update_conversation_notes' or 'modify_conversion_notes'. There's no mention of prerequisites, context requirements, or exclusions. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool produces a report but doesn't describe what the report contains, how it's formatted, whether it's read-only or has side effects, or any performance considerations. For a reporting tool with 5 parameters and no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids unnecessary elaboration. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, but with an output schema), the description is incomplete. It states what the tool does but lacks details on behavior, parameter usage, and differentiation from siblings. The output schema mitigates some gaps by documenting return values, but the description should do more to guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles provide minimal context. The description doesn't explain any parameters—it doesn't mention what 'product_slug', 'client_id', 'lookback_days', etc., mean or how they affect the report. With 5 parameters and no schema descriptions, the description fails to compensate, leaving semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Produce a voice-of-customer report combining outcome metrics and confirmed/uninterested conversation samples.' It specifies the verb ('produce'), resource ('voice-of-customer report'), and key components (outcome metrics, conversation samples). However, it doesn't explicitly differentiate from sibling tools like 'compare_confirmed_vs_uninterested' or 'crm_state_stats', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, appropriate contexts, or exclusions. Given sibling tools like 'compare_confirmed_vs_uninterested' that might handle similar data, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation ('Return') but lacks details on permissions, rate limits, data freshness, or output format. The mention of 'canonical' hints at standardized data, but behavioral traits like whether it's idempotent, side effects, or error handling are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste—every word contributes to understanding the tool's purpose. It efficiently conveys key information without redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 1 parameter (0% schema coverage), and no usage guidelines, the description is incomplete for a tool that might involve client-specific data. It covers purpose but lacks context on behavior and parameters, making it minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and there is 1 parameter ('client_id') with no description in the schema. The tool description does not mention parameters at all, failing to compensate for the low coverage. However, with 0 required parameters, the baseline is 4, but since the description adds no parameter semantics, it's scored lower at 3 for minimal adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and resource ('canonical CRM conversion states'), specifying they are for 'recategorization'. It distinguishes from siblings like 'crm_customers_by_state' or 'crm_state_stats' by focusing on available states rather than customer data or statistics. However, it doesn't explicitly differentiate from 'change_crm_state', which might involve similar states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'for recategorization', which implies usage context but doesn't specify when to use this tool versus alternatives like 'change_crm_state' or 'crm_customers_by_state'. No explicit guidance on prerequisites, exclusions, or comparisons with sibling tools is provided, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is returned but doesn't cover critical behavioral aspects: whether this is a read-only operation, if it requires authentication, potential rate limits, error conditions, or side effects. The description is informative about output content but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, bulleted return values, and specific usage guidance—all in just 4 sentences. Each sentence adds value, though the bulleted list could be more integrated into the narrative flow. Overall, it's appropriately concise without being overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which covers return values), the description's focus on what data is returned is somewhat redundant. However, for a tool with 3 parameters (0% schema coverage) and no annotations, the description should do more to explain parameter meanings and behavioral context. It's adequate but has clear gaps in parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides no information about what 'product_slug', 'session_id', or 'client_id' represent, their formats, or how they relate to the onboarding process. The description mentions 'product/session' but doesn't explain these specific parameters, leaving significant gaps in understanding how to properly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to return a 'canonical onboarding progress view' with specific data points like current phase and next required action. It distinguishes itself by focusing on recovery scenarios for partial/failed onboarding runs, though it doesn't explicitly differentiate from all sibling tools like 'get_onboarding_prompt_pack' or 'run_full_agentic_onboarding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'for recovery if a previous onboarding run was partial or failed.' This gives clear context for its primary use case. However, it doesn't specify when NOT to use it or mention alternatives among sibling tools like 'get_onboarding_prompt_pack' or 'submit_onboarding_artifacts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'returns' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, or whether it's idempotent. For a tool with zero parameters and no annotations, more transparency about its safe usage would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: it starts with the core purpose ('Zero-context onboarding playbook'), followed by specifics on what it returns. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple, no parameters) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and output content. However, without annotations, it could benefit from more behavioral context, but the output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate. Baseline is 4 for zero-parameter tools, as there's no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it provides a 'zero-context onboarding playbook' with 'recommended call sequence, common guardrails, and recovery hints.' This specifies the verb (returns onboarding guidance) and resource (playbook for agents). However, it doesn't explicitly differentiate from sibling tools like 'run_full_agentic_onboarding' or 'get_onboarding_prompt_pack,' which appear related to onboarding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('zero-context onboarding playbook for agents using this MCP server'), suggesting it's for initial setup or orientation. However, it doesn't explicitly state when to use this versus alternatives like 'run_full_agentic_onboarding' or provide clear exclusions. The guidance is present but not detailed enough for explicit decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool can return a checkout link if blocked on credits, which is useful context about conditional outputs. However, it doesn't describe permissions needed, rate limits, error conditions, or what 'readiness' evaluation entails. The description adds some value but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. The first sentence states the core purpose, followed by two brief but informative sentences about additional behaviors. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, conditional behaviors) and the presence of an output schema (which reduces need to describe return values), the description is moderately complete. It covers the main purpose and key conditional behavior (checkout link), but lacks details about parameter meanings, error cases, and what 'readiness evaluation' involves. The output schema existence helps, but more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 8 parameters, the description must compensate but adds minimal parameter semantics. It only explains the 'start_now' parameter's purpose ('to attempt campaign launch'). Other parameters like 'product_slug', 'outbound_per_day', 'checkout_plan', and URL parameters remain unexplained in the description, leaving most parameter meanings unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Evaluate readiness and optionally start campaign immediately.' It specifies the verb ('evaluate readiness', 'start campaign') and resource ('campaign'), and distinguishes it from siblings by mentioning its use 'after onboarding reaches targeting approval.' However, it doesn't explicitly differentiate from all sibling tools like 'list_campaigns' or 'run_full_agentic_onboarding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Use this after onboarding reaches targeting approval.' It also mentions an alternative action via the 'start_now' parameter. However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool 'Returns created client_id and (by default) logs this MCP session into it,' which adds valuable behavioral context about side effects. However, it doesn't cover permissions needed, error conditions, or rate limits, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose first, then requirements, returns, and next steps. Each sentence adds value with no fluff. It could be slightly more concise by combining some points, but overall it's well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and 4 parameters with 0% schema coverage, the description does a decent job. It covers the core purpose, key parameters, behavioral effects, and workflow context. However, it misses details on optional parameters and full behavioral transparency, preventing a score of 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions two required parameters ('business_name' and 'email'), which helps, but doesn't explain the optional 'source' or 'auto_login' parameters. Since it partially addresses the 4 parameters but leaves half undocumented, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a brand-new Signal Found client account for onboarding.' It specifies the verb ('Create'), resource ('client account'), and context ('for onboarding'). However, it doesn't explicitly differentiate from sibling tools like 'login_with_client_id' or 'run_full_agentic_onboarding', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it's for 'onboarding' and specifies a 'Next step after success: call create_new_product.' This gives practical guidance on when to use it in a workflow. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'login_with_client_id' for existing accounts, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions this is a 'summary' tool (implying read-only), it doesn't explicitly state whether it requires authentication, has rate limits, or what happens when client_id is null. The description adds some context about being a 'first operational tool after login' but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two focused sentences. The first sentence explains what the tool does, and the second provides clear usage guidance. Every word serves a purpose with zero wasted content, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and only 1 parameter, the description provides good context about purpose and usage. However, it could better explain parameter behavior (especially the nullable client_id) and clarify what 'summary' means operationally. For a relatively simple tool with output schema, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'for a client' which implies the client_id parameter, but doesn't explain what happens when client_id is null (the default) or whether this affects the scope of the summary. With 1 parameter at 0% coverage, the description adds minimal semantic value beyond what's implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'command-center summary for a client' covering products, campaign health, close-rate, and recommendations. It specifies the resource (client summary) and content areas, though it doesn't explicitly distinguish from all sibling tools like 'portfolio_close_rate' or 'sf_health' which might overlap in some metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Best first operational tool after login when the user asks for "what should we do next?"' This gives clear context for when to use this tool versus alternatives, making it easy for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'persists' artifacts (implying a write operation) and returns 'policy/preview', which adds some behavioral context. However, it lacks details on permissions, side effects, error handling, or rate limits. The mention of prerequisites and typical next steps offers partial transparency but doesn't fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, prerequisites, typical next step, and formats. Each sentence adds value, such as clarifying parameter formats and usage context. It could be slightly more concise by integrating the format details into the purpose statement, but overall it's efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains the tool's purpose, usage guidelines, and parameter formats, which compensates for the lack of annotations. The presence of an output schema means the description doesn't need to detail return values, allowing it to focus on input and behavioral context. However, it could improve by addressing all parameters and providing more behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning for 'keywords' and 'subreddit_groups' by specifying formats ('list[str]' and a structure example), which helps clarify these parameters. However, it doesn't address 'product_slug', 'session_id', 'client_id', or 'keyword_search_params', leaving half of the parameters undocumented. This partial coverage results in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Persist targeting artifacts (keywords/subreddits) and return policy/preview.' It specifies the verb ('persist'), the resources ('targeting artifacts'), and the outcome ('return policy/preview'). However, it doesn't explicitly distinguish this tool from sibling tools like 'modify_keywords' or 'modify_subreddits', which appear to handle similar resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidelines with prerequisites ('prompt pack must be acknowledged for `session_id`', 'artifacts should already be saved for best results') and a typical next step ('approve targeting...'). It mentions an alternative ('run_full_agentic_onboarding') but doesn't explicitly state when to use this tool versus other sibling tools like 'configure_targeting' or 'submit_onboarding_artifacts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the dual read/write behavior and mentions 'update writes explicit keyword list,' implying mutation. However, it doesn't cover important behavioral aspects like authentication needs, rate limits, side effects, or what happens to existing keywords not in the new list. The description adds some context but leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, usage guidelines, and payload details. Every sentence earns its place by providing essential information without redundancy. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the tool's dual read/write nature and explains some parameters, but misses 'product_slug' and 'client_id' semantics. For a mutation tool with no annotations, it should provide more behavioral context about permissions, side effects, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'keywords' as a list of strings and details 'search_params' with sort options, time filters, and per_keyword_limit. However, it doesn't explain 'product_slug' or 'client_id' parameters at all. The description adds valuable semantics for 2 of 4 parameters, partially compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read or update keyword targeting with optional search parameters.' It specifies both read and write operations on keyword targeting, which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'configure_targeting' or 'submit_agent_targeting', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'How to use' section provides clear guidance: call without 'keywords' to inspect current config, or with 'keywords' to update. This gives explicit when-to-use instructions for read vs. write modes. However, it doesn't mention when to use this tool versus sibling targeting tools or any prerequisites beyond the required 'product_slug' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a creation/mutation operation (implied by 'create'), mentions authentication requirements, describes the response structure (product creation result, context packet, prompt pack), and outlines post-success workflow. It doesn't mention rate limits, idempotency behavior (though idempotency_key parameter exists), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: primary function, response details, prerequisite, and next steps. Each sentence earns its place, though it could be slightly more concise by integrating the response details into the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation/mutation with 6 parameters), no annotations, but with an output schema present, the description does well. It covers purpose, prerequisites, response structure, and next steps. The main gap is lack of parameter explanations, but the output schema reduces the need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'client_id' in the prerequisite context but doesn't explain any of the 6 parameters (product_name, website_url, client_id, session_id, folder_id, idempotency_key) or their purposes. The description adds no parameter semantics beyond what's minimally implied by the prerequisite mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a product and initializes an agent onboarding session context. It specifies the action ('create a product') and the resource ('product'), but doesn't differentiate from sibling tools like 'create_new_account' or 'list_products' beyond mentioning the onboarding context initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: a prerequisite (authenticated session via 'login_with_client_id' or provide 'client_id'), and a clear next step after success ('call run_full_agentic_onboarding' or run staged tools manually). This gives concrete when-to-use and what-follows instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool can both read and update, and specifies that updates require all three canonical keys for consistency. However, it doesn't mention permissions, side effects, error handling, or rate limits, which are important for a mutation tool. The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, usage instructions, and key specifications. Every sentence adds value, with no wasted words. It's front-loaded with the core purpose and efficiently communicates essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and no annotations, the description does a good job explaining the dual read/update functionality and parameter expectations. However, as a mutation tool with 3 parameters and 0% schema coverage, it should ideally clarify all parameter semantics and more behavioral traits (like idempotency or error cases) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of the 'conversion_notes' parameter by listing the three expected keys and their string value requirements. However, it doesn't clarify 'product_slug' or 'client_id' parameters, which are also in the schema. The description adds meaningful context for one parameter but not all three.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read or update conversion notes with explicit required key names.' It specifies both read and update operations and mentions the resource (conversion notes). However, it doesn't explicitly differentiate from sibling tools like 'update_conversation_notes' or 'get_conversation_notes', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'How to use' section provides explicit guidance on when to call without parameters (to inspect) and when to provide all three keys (for updates). This gives clear operational context. However, it doesn't mention when to use this tool versus alternatives like 'update_conversation_notes' or 'get_conversation_notes', which are sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: it mentions validation ('validate'), persistence ('persist'), and prerequisites, which helps understand the tool's behavior. However, it doesn't disclose critical traits like whether this is a read-only or destructive operation, authentication needs, error handling, or rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured, with clear sections: a purpose statement, prerequisites, common use, and expected formats. Each sentence earns its place by adding specific value, such as clarifying artifact schemas or usage contexts, with no redundant or vague information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, 0% schema coverage) and the presence of an output schema (which reduces the need to explain return values), the description is fairly complete. It covers purpose, usage, prerequisites, and parameter semantics for key artifacts. However, it could be more complete by addressing behavioral aspects like safety or error handling, especially since annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains the expected formats for 'market_position', 'conversion_notes', and 'funnels', providing semantic context that the schema lacks (e.g., 'market_position: patch object with market position keys'). This compensates well for the schema's lack of descriptions, though it doesn't cover all parameters like 'product_slug' or 'client_id' in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate and persist core onboarding artifacts for a product/session.' It specifies the verb ('validate and persist') and resource ('core onboarding artifacts'), making the action clear. However, it doesn't explicitly distinguish this tool from sibling tools like 'modify_market_positioning' or 'modify_funnels', which appear to handle similar artifacts individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidelines with prerequisites ('prompt pack must be acknowledged for `session_id`') and common use cases ('called by `run_full_agentic_onboarding`', 'can also be used for staged/recovery runs'). It mentions a sibling tool ('run_full_agentic_onboarding') as a caller, but doesn't explicitly state when to use this tool versus alternatives like the individual modify tools (e.g., 'modify_market_positioning'), which could handle similar updates separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a read operation that returns authentication context, but doesn't disclose behavioral details like what specific data is included in the context, whether it's cached or real-time, error conditions, or authentication requirements beyond the implied session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose without any wasted words. It's perfectly front-loaded with the essential information and earns its place as the complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (0 parameters, has output schema), the description is reasonably complete for understanding what it does. However, with no annotations and a read operation that returns authentication context, it could benefit from slightly more detail about what 'client context' specifically includes or how it relates to the session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the empty input schema is self-explanatory for this context-retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Return') and resource ('currently authenticated client context for this MCP server session'), distinguishing it from all sibling tools which focus on CRM, campaigns, products, or onboarding operations rather than session authentication context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing the current client context, but provides no explicit guidance on when to use this versus alternatives like 'login_with_client_id' or 'logout_client_context', nor any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that this establishes authenticated context for the session and that the client_id persists across subsequent tool calls unless overridden. However, it doesn't mention authentication failure modes, session duration, or whether this creates a new session or reuses existing ones. For an authentication tool with zero annotation coverage, this is adequate but leaves important behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. Three sentences cover: 1) core purpose, 2) when to use it, and 3) how it affects subsequent operations. Every sentence earns its place with no wasted words, and the most important information (authentication requirement) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is an authentication tool with no annotations but with an output schema (which presumably handles return values), the description provides good contextual completeness. It explains the tool's role in the workflow, when to invoke it, and how it affects other operations. The main gap is lack of information about authentication failure handling or session management details, but the presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. While it doesn't explicitly describe the 'client_id' parameter, it provides crucial semantic context: this client_id establishes the authenticated session context that most other tools will use by default. This adds significant meaning beyond the bare schema. With only one parameter, the description effectively explains its role in the broader system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Authenticate MCP session to a Signal Found client account.' This specifies the verb ('authenticate') and resource ('MCP session'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'logout_client_context' or 'current_client_context' beyond being an authentication tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidance: 'Run this at the start of each session before business tools' specifies when to use it, and 'Most tools require authenticated context and will use this session client id unless you pass an explicit `client_id` argument' explains the consequences of using it and how it interacts with other tools. This gives clear context for when and why to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that updates are 'replace-style' and mentions 'explicit shape validation,' which adds useful behavioral context. However, it doesn't cover permissions, rate limits, or error handling, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the purpose, followed by usage guidelines and parameter details. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to explain return values) and no annotations, the description does a good job covering usage and parameter semantics. It could improve by addressing missing parameter details or behavioral aspects like auth needs, but it's largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'funnels' parameter in detail with expected item shape (url, description, primary_use_case, qualification), adding significant meaning beyond the schema. It doesn't cover 'product_slug' or 'client_id', but the high value on 'funnels' justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read or replace funnels with explicit shape validation.' It specifies the verb ('Read or replace') and resource ('funnels'), and mentions shape validation. However, it doesn't differentiate from sibling tools like 'modify_keywords' or 'modify_subreddits' that follow similar patterns, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Call without `funnels` to inspect current funnel list' and 'Update is replace-style: provide the full intended funnels list.' This clearly indicates when to use it for reading vs. updating and specifies the update behavior, with no misleading information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool can both read and update, and mentions an expected format for updates. However, it lacks details on permissions, side effects (e.g., whether updates are reversible), rate limits, or error handling. For a mutation-capable tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it starts with a clear purpose statement, followed by a 'How to use' section with bullet points, and ends with parameter details. Every sentence adds value without redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read/update operations, 4 parameters with 0% schema coverage) and the presence of an output schema (which reduces need to explain return values), the description is fairly complete. It covers core usage and key parameter semantics but misses details on other parameters and behavioral aspects like error handling or permissions, which are important for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of `subreddit_groups`: how to use it for read vs. update and the expected item shape with `subreddits` list format. However, it doesn't cover other parameters like `product_slug`, `client_id`, or `run_quality_check`, leaving some undocumented. The value added for the key parameter is substantial but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read or update subreddit targeting groups.' It specifies both read and update operations with the resource being 'subreddit targeting groups.' However, it doesn't explicitly differentiate this tool from potential siblings like 'configure_targeting' or 'submit_agent_targeting,' which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Call without `subreddit_groups` to inspect current targeting' and 'Update expects `groups` format used by onboard API targeting endpoint.' This clearly indicates when to use it for read vs. update operations and references an external format standard, offering complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the behavioral effect (clearing authentication context) and scope (session-level), which is adequate for a simple operation. However, it doesn't mention potential side effects like whether this affects other tools' operations, if re-authentication is required afterward, or what happens to in-progress operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without any unnecessary words. It's front-loaded with the essential action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, has output schema), the description provides sufficient context about what the tool does. The existence of an output schema means the description doesn't need to explain return values. However, for an authentication-related operation, it could benefit from slightly more detail about consequences or typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the empty input schema is self-explanatory for a parameterless operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Clear') and the resource ('active authenticated client context for this MCP server session'). It distinguishes itself from siblings like 'login_with_client_id' and 'current_client_context' by being the inverse operation that removes authentication state rather than establishing or querying it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'active authenticated client context' and 'this MCP server session', suggesting it should be used when authentication needs to be terminated. However, it doesn't explicitly state when NOT to use it or name specific alternatives like 'login_with_client_id' for re-authentication scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies the tool's dual read/update behavior and patch semantics, which is helpful. However, it doesn't mention permissions, side effects, or response format, leaving gaps for a mutation-capable tool. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear usage instructions and parameter details. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dual read/update functionality, 3 parameters with 0% schema coverage) and the presence of an output schema, the description is largely complete. It covers purpose, usage, and parameter semantics well, though it could benefit from mentioning authentication or error handling. The output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains the semantics: 'product_slug' is implied as the target, 'market_position_patch' is detailed with expected keys and patch behavior, and 'client_id' is not mentioned but its optional nature is inferred from usage guidance. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual purpose: 'Read or update market positioning with explicit format guidance.' It specifies the resource ('market positioning') and the actions ('read' and 'update'), though it doesn't explicitly differentiate from sibling tools like 'configure_product_strategy' or 'configure_targeting' that might handle related aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call without `market_position_patch` to inspect current data before editing' and 'Send only keys you want to change (patch semantics).' This clearly indicates when to use the tool for reading vs. updating and how to structure updates, with no misleading or missing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as fetching 'server-curated prompt contracts,' implying a read-only operation, but does not disclose behavioral traits like authentication needs, rate limits, or error handling. The description adds some context about the types of contracts but lacks details on the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage guidelines and parameter details. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 0% schema coverage) and the presence of an output schema, the description is reasonably complete. It covers purpose, usage, and parameter semantics for 'artifact,' but lacks details on other parameters and behavioral aspects. The output schema likely handles return values, so the description's focus on input and usage is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the 'artifact' parameter's purpose and listing its possible values (clarifications, market_position, etc.). However, it does not address 'product_slug' or 'client_id' parameters. Since there are 3 parameters and the description adds meaningful semantics for one, it partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetch') and resources ('server-curated prompt contracts'), and it distinguishes this tool from its sibling 'artifact' for focused contracts. It explicitly lists the types of required onboarding outputs (clarifications, conversation transcript, etc.), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when an agent needs exact formatting/expectations before generating') and lists specific use cases. It also distinguishes when to use the 'artifact' parameter for focused contracts, offering clear alternatives and context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively describes the tool's read-only, diagnostic nature by listing what it confirms (connectivity, auth state, configuration). However, it lacks details on potential side effects (e.g., whether it logs activity, affects rate limits, or caches results), error behavior, or response format. The description adds useful context but doesn't fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses two short sentences: the first states the purpose, and the second provides specific usage guidelines. Every word earns its place, with no redundancy or fluff. The information is front-loaded, making it easy for an agent to quickly understand the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, diagnostic function) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, usage context, and what the tool checks. However, for a tool with no annotations, it could benefit from more behavioral details (e.g., idempotency, error handling). The output schema mitigates some gaps, but the description alone isn't fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description appropriately doesn't discuss parameters, as none exist. It focuses on the tool's purpose and usage context, which is sufficient. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully covers the (empty) parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs and resources: 'Preflight check for MCP -> onboard_api connectivity and auth context.' It explicitly distinguishes this diagnostic/verification tool from all sibling tools, which are operational (e.g., create_new_account, list_campaigns, modify_keywords). The description avoids tautology and provides a concrete, distinct function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, actionable guidance on when to use this tool: 'Use this first in a new session to confirm...' It specifies the exact context (new session initialization) and the preconditions it verifies (backend reachability, auth state, default client id). This clearly differentiates it from sibling tools that perform operational tasks rather than session setup validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes the multi-stage orchestration, partial failure handling ('On partial failure, returns failed_stage, retry_hint, and completed stages'), and specific requirements ('clarifying_questions must have exactly 3 items', 'pass valid schema payloads'). It doesn't mention authentication needs, rate limits, or idempotency, but covers the core execution behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero waste: first sentence states the core purpose, second specifies the target user, bullet list outlines the orchestrated stages, requirements section highlights critical constraints, and final sentence explains error handling. Every sentence earns its place, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (16 parameters, multi-stage orchestration, no annotations) but presence of an output schema, the description is reasonably complete. It explains the orchestration flow, requirements, and error handling well. The output schema will document return values, so the description appropriately focuses on execution behavior rather than return format. It could potentially mention authentication context given the sibling tools include login/logout functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 16 parameters (10 required), the description compensates significantly by explaining the purpose of key parameters: clarifying_questions must have exactly 3 items, and artifacts/targeting require valid schema payloads. It also implicitly explains parameters through the staged flow description (e.g., clarifying_questions/answers relate to clarifications stage). While not covering all 16 parameters individually, it provides crucial semantic context missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute the full staged onboarding flow end-to-end in one call.' It specifies the exact sequence of stages orchestrated (prompt-pack version, clarifications, conversation, artifact validation, targeting submit, readiness snapshot) and distinguishes it from sibling tools by emphasizing it's for 'zero-context agents that want a safe default path' rather than using individual stage tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Intended for zero-context agents that want a safe default path.' This provides clear guidance that this is an all-in-one alternative to using individual onboarding stage tools (like submit_onboarding_artifacts, submit_agent_targeting, etc.), helping the agent choose between comprehensive vs. granular approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the three operational modes, message generation options, dependency on a Chrome extension, and failure condition if extension is offline. However, it lacks details on rate limits, error handling, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with zero wasted sentences. It front-loads the core purpose, then details modes, message options, and prerequisites in clear, bullet-like sections without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but with output schema), the description is mostly complete. It covers operational modes, message handling, and prerequisites well. The output schema existence means return values needn't be explained, but some parameter semantics (e.g., product_slug, limit) and edge cases are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant semantic context for parameters like target_username, crm_reply_to, batch_from_working_leads, message, and generate_message by explaining their roles in the three modes and message generation. However, it doesn't cover all 9 parameters (e.g., product_slug, client_id, batch_id, limit remain unexplained).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send Reddit DMs to scraped leads via the Signal Found Chrome extension.' It specifies the action (send), target (Reddit DMs), and mechanism (Chrome extension), distinguishing it from sibling tools that focus on CRM management, configuration, or analytics rather than direct messaging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by detailing three distinct modes (target_username, crm_reply_to, batch_from_working_leads) and specifying that exactly one must be set. It also explains when to use manual vs. auto-generated messages and notes prerequisites like the Chrome extension being online.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sf-mcp MCP server](https://glama.ai/mcp/servers/signal-found/sf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/signal-found/sf-mcp)

Score Badge

Copy to your README.md:

[![sf-mcp MCP server](https://glama.ai/mcp/servers/signal-found/sf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/signal-found/sf-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/signal-found/sf-mcp'

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