Space Monkey Mailchimp Dashboard MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining the returned data categories and the account scope, compensating for the absence of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: the first clause states the core purpose, the middle specifies the returned information, and the final clause gives concrete usage direction. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only introspection tool, the description fully covers what the tool does, what it returns, and when to call it. The absence of an output schema is adequately mitigated by explicitly listing the returned data categories.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema coverage is 100%, so there is no parameter ambiguity. The description appropriately implies the operation uses the API key's own identity and needs no user-supplied arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Introspect') and resource ('the API key's own account') and details what is inspected: tier, entitlements, quota usage, and project count. It clearly distinguishes this account-focused tool from the sibling get/list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells an agent when to use it: check headroom or diagnose a 403/429 before retrying. It does not explicitly name alternatives or exclusion conditions, but the use cases are clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a safe, read-only, idempotent operation. The description adds the single-campaign scope and the report content categories, which is useful, but it does not describe return format, pagination, or potential variations in report completeness. This is similar to the calibrated get_calls example: moderate added context but no deeper behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured sentence with no filler. It front-loads the action and resource, lists the report contents, and ends with a clear usage cue. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only tool with strong annotations, the description is largely complete: it identifies the target resource, the report contents, and the proper workflow. The absence of an output schema makes the lack of any return-structure detail a minor gap, but the listed report sections give an agent enough to work with.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions for projectId or campaignId, and the description does not explain either parameter. It only refers to 'a campaign' generically, which weakly hints at campaignId but does not compensate for the 0% schema coverage. The parameter names are conventional, but the description itself adds almost no semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Load one campaign's full report' and enumerates the report's contents (funnel, click-to-open, geography, metadata). The single-campaign scope clearly distinguishes it from account-level or list-based sibling tools like sm_list_campaigns and sm_get_account.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Use after you have identified a campaign of interest' gives clear contextual guidance on when to invoke this tool. It does not explicitly name alternatives or state when not to use it, but the workflow cue is strong enough for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read operation. The description adds value by specifying the analytical scope (engagement distribution, tag and segment summaries, growth baselines, campaign consistency), which goes beyond what annotations provide. It does not mention data types, pagination, or return format, but given the annotations cover the safety profile and the description conveys the analytical intent, the behavior is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and front-loaded with the core purpose. The first sentence lists the key analytical areas, and the second provides a conditional usage hint. There is no redundant or filler language; every word contributes to clarifying the tool's purpose. This is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (six parameters, no output schema, no nested objects), the description provides a reasonable high-level overview but lacks detail on how parameters affect the output, what data ranges are expected, or how results are presented. Since there is no output schema, the description could have explained the return value's structure, but it does not. However, the annotations indicate safety and idempotency, and the description covers the core analytical capabilities. The missing parameter semantics and return format are notable gaps, so a 3 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the six parameters have descriptions in the schema. The tool description does not explain any parameters either; it only describes the high-level purpose. With parameters like 'startDate', 'endDate', 'campaignId', 'minSendVolume', and 'maxSendVolume', an agent might infer their meaning from names, but 'projectId' is only marked as required without explanation, and the date format (e.g., ISO 8601) is not specified. Since the description carries the burden to compensate for schema gaps but does not, a score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Get') and resource ('deeper audience analytics'), and enumerates concrete content areas: engagement distribution, tag and segment summaries, growth baselines, and campaign consistency. It distinguishes itself from basic insights by noting it is for when basic insights cannot explain a change, though it does not explicitly name the basic tool in the description. The presence of sibling tools like sm_get_insights_basic and sm_get_insights_expert confirm the distinction, but the description itself only implies it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage condition: 'Use when basic insights cannot explain a change.' This orients the agent toward when to select this tool over alternatives. However, it does not explicitly state when NOT to use it, nor does it mention alternatives like sm_get_insights_expert. Given the sibling list includes both basic and expert variants, additional guidance on when to choose expert over advanced would be helpful, but the stated condition is sufficient for common use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent behavior; the description adds that the tool returns 'headline performance', 'averages', and 'trends', which gives some indication of output shape. It does not revealing more operational details (e.g., what 'headline' excludes, pagination, response size, quotas, or how dates are interpreted), so it stays at a mid level.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences with no filler. The core statement ('Get a computed campaign and audience performance …') is front-loaded, and the usage prompt appears second. It is appropriately simple and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has nine parameters and no output schema, but the description only covers the high-level outcome ('headline', 'averages', 'trends'). It does not communicate how to narrow the generated data (date range, campaign, send volume), what the default sort order means, or whether this is a simple return of always aggregated info. Bund on this description alone, an agent can only safely call with projectId and it will miss the available filtering capability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain any of the 9 non-namespace parameters except a loose 'project' that maps to projectId. startDate, endDate, campaignId, search, minSendVolume, maxSendVolume, and sorting fields remain semantically undefined, exceeding the tool unusable without external knowledge.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get headline campaign and audience performance') and resource ('project'), with useful detail about what kind of metrics are involved (averages, trends). 'Start here' vaguely positions it as the entry point among insight siblings, but without naming them the differentiation is weaker than it could be.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear opening scenario ('Start here for 'how are we doing''), which suggests a starting point, but does not explicitly describe when to switch to sm_get_insights_advanced or sm_get_insights_expert. There is no 'when not to use' or alternative-name comparison, so guidance remains a single implied prompt rather than solid routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the diagnostics returned, but does not disclose behavioral details such as required inputs, result shape, or edge cases. It adds some value without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler: the first states what the tool does and lists diagnostics, the second states when to use it. It is front-loaded and appropriately sized for the tool's role.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given seven parameters, no output schema, and no parameter descriptions, the description is not complete enough for an agent to call the tool correctly with confidence. It provides a useful high-level purpose but omits required input meaning, optional filter semantics, and output expectations, and it does not clarify how 'expert' differs from 'advanced' or 'basic' insights.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for explaining parameters, but it does not. None of the seven parameters (projectId, startDate, endDate, campaignId, minSendVolume, maxSendVolume, heatmapTimezone) are explained, though the send-time heatmap category loosely hints at heatmapTimezone. This leaves the agent without meaningful parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get expert diagnostics') and lists concrete diagnostic categories: campaign fatigue, subject-line keywords, send-time heatmap, monthly trend, audience health. This makes the tool's function clear, but it does not explicitly distinguish it from sibling tools like sm_get_insights_basic or sm_get_insights_advanced.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Use to explain why performance is moving' gives a clear use case for the tool. However, it does not mention when not to use it or suggest alternative sibling tools, so there is no exclusion or comparison guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations by clarifying that this returns knowledge documents as tool output for clients unable to access MCP resources. No hidden mutation, auth, or side-effect concerns are left undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence achieves clarity and includes the key usage directive. Every part earns its place; no redundant phrases or clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool returns for whom, and when to invoke it ('before interpreting any Space Monkey metrics'). Since annotations are already rich and the only parameter is fully documented in the schema, nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the optional 'topic' parameter, its enum values, and the default behavior of fetching all documents. The description adds no extra parameter-level meaning, but with ~100% schema coverage the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') and clearly identifies the resource being returned: Space Monkey's MCP knowledge documents. It also enumerates the document types (analyst preamble, metric guardrails, OpenAPI schema URL), which distinguishes this from typical data-fetching sibling tools like sm_get_account or sm_get_insights.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: for clients that cannot read MCP resourcesandar to consult this before interpreting any Space Monkey metrics. It does not explicitly name sibling alternatives or when not to use the tool, but the use-case instruction is concrete enough for an agent to route appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by enumerating the specific data fields returned and the at-risk/bot-detection flags, which are behavioral outputs beyond the annotations. However, it does not disclose potential null fields, error conditions, or whether the profile is always fully populated, so it adds moderate but not rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero filler. The first sentence front-loads the action, resource, and field list; the second sentence gives use cases. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only single-resource lookup with two required parameters and no output schema, the description is nearly complete. It names the fields returned and the use cases. The only gap is that it does not clarify the meaning/format of the two parameters (especially projectId) or note any access prerequisites, but the annotations cover safety and idempotency, so the overall context is strong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for parameter meaning. The description does not explain what projectId or subscriberHash mean or how to obtain them, beyond the schema's pattern constraint on subscriberHash. It names the resource ('member') but not the identifier semantics. Baseline 3 is appropriate because the description adds some context (member profile) but leaves the two required parameters under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Load'), a specific resource ('one member's full profile'), and enumerates the exact fields returned (title, company, tags, clicked URLs, engagement percentile, at-risk state, bot detection). It also names two concrete use cases (pre-call briefs, enriching a shortlist). This clearly distinguishes it from sibling tools like sm_get_member_overview or sm_list_members.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases ('Use for pre-call briefs and to enrich a shortlist'), which tells an agent when to invoke this tool. It does not explicitly state when NOT to use it or name alternative tools (e.g., sm_get_member_overview for a lighter profile, sm_list_members for bulk), so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds real behavioral value beyond those: the result-set sparsity behavior (often empty despite engagement) and the implied expectation that nonzero interactions are needed. This changes how an agent should handle the response, which qualifies as meaningful behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The core purpose is front-loaded in sentence one, and the behavioral caveat follows in sentence two. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 15 parameters including four enums, date filters, multiple numeric bounds, and a cursor-based pagination field, plus no output schema, the description is far too thin to fully prepare an agent. It covers the 'what' and the sparsity caveat but says nothing about filtering behavior, pagination, or response shape, leaving substantial room for mis-invocation on a complex input surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 15 parameters, so the description carries the full burden of explaining parameter intent — but it mentions none of them. The only implicit signal is that subscriberHash and projectId identify 'one member' and her campaigns. Date filters, sorting semantics, opened/clicked filters, time-to-open/click bounds, and pagination are all left to the agent to infer from bare names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('List the individual campaigns one member received, opened or clicked') and characterizes it as an 'email-level drill-down', which clearly separates it from aggregate sibling tools like sm_get_insights_advanced and member-profile tools like sm_get_member. It states both the scope (one member) and the grain (individual campaigns) explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It conveys clear usage context by warning that this drill-down 'is often empty even for highly engaged members' and instructs the agent to 'always keep a fallback' — actionable guidance for call planning. It does not, however, explicitly name alternatives or state when NOT to use this tool, so it stops short of the top of the scale.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds the aggregate-distribution context, but it does not disclose output format, granularity, or whether countryCode acts as a filter, so there is only moderate added transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences deliver the purpose and usage guidance with no filler. The key object ('country and region distribution') is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool the description covers the core result and a use case, but with no output schema it does not describe the return shape or the countryCode effect. The missing parameter semantics and return details leave the agent to guess at call behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema-description coverage, the description needed to document the parameters. It only indirectly implies projectId through 'a project's members' and says nothing about countryCode, leaving a required input concept and the optional filter unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get the country and region distribution of a project's members.' This is explicit and clearly distinguishes the tool from siblings like sm_get_member or sm_get_member_growth, even without naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use for territory, event and travel-planning questions' gives clear, concrete situations where the tool is appropriate. It does not state exclusions or name alternative tools, so it stops just short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds what data is returned (signup cohorts, churn timeline, cohort retention) but doesn't add contextual behavior like time ranges or aggregation semantics. With low annotation bar, this is broadly sufficient, though not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. Purpose and usage guidance packed efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover safety/idempotency and no output schema existsations? Sibling set has many similar get/list tools; description names result components but not specific lookback/period/format or how the parameter shapes results. Adequate for simple param but lacks a bit context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

schema description coverage is 0% and the description does not explain projectId or how it affects the query. The single required parameter is left to the agent to infer from its name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get signup cohorts, churn timeline and cohort retention.' It clearly distinguishes this from sibling tools like sm_get_member_overview or sm_list_members by naming the exact growth/retention metrics it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use for list-growth and attrition questions,' which gives the agent a clear selection criterion. It does not mention when not to use it or name an alternative tool, but the use-case guidance is strong enough for typical routing decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar for additional behavioral disclosure is lower. The description adds context beyond the annotations by indicating the response is an aggregate/summary rather than detailed member data, and 'quick' signals a lightweight operation. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The core purpose and output content are front-loaded, and the usage guidance is appended in a compact final clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description adequately conveys what will be returned by listing the breakdown dimensions. It does not detail exact response formatting, but the absence of an output schema is partly compensated by the enumerative description of the aggregate result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the undocumented projectId parameter. It only echoes 'for a project,' which maps the parameter to the concept of a project but does not explain the expected format, how to obtain it, or any constraints beyond minLength: 1. The single obvious parameter mitigates, but the gap remains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') with a clear resource ('aggregate audience composition for a project') and enumerates the breakdowns it provides (totals, status, rating, rep, language). This makes it clearly distinct from sibling tools like sm_get_member, sm_get_member_segments, or sm_get_insights_basic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence, 'Use for a quick shape-of-the-list answer,' gives a clear context for when to choose this tool. It stops short of explicitly naming alternatives or saying when not to use it, but the use case is specific enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds result content ('engagement and status breakdowns') but no additional behavioral traits such as pagination, scoping, or response details. With strong annotations, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the core resource and action, followed by a practical usage note. No filler or repetition of the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one required parameter and no output schema, the description covers what is returned and why to use it. It does not detail the return structure, but the engagement/status breakdown mention plus annotations make it sufficiently complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain the projectId parameter at all. The parameter name is somewhat self-explanatory, but the description provides no additional meaning or guidance, and with low schema coverage it was expected to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves tags and segments with engagement and status breakdowns, naming a specific resource and operation. It does not explicitly contrast itself with sibling tools, but the unique resource ('tags and segments') distinguishes it from the other get/list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a concrete use case: 'Use to turn an event or interest tag into a working audience.' This provides clear when-to-use context, though it does not mention exclusions or alternatives among the many sibling get tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey the tool's behavioral profile. 'Replay one member's raw activity events in time order' strongly implies a read-only retrieval operation, and the use case signals no side effects. However, it does not mention pagination, output shape, filtering semantics, or whether the timeline is normalized or strictly raw, which are relevant given the many schema fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core action and resource. It states the purpose in one short clause followed by a concrete use case. It loses a point because 'raw activity events' is not further qualified, but the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description is the entire behavioral contractate. It covers the basic read/replay intent and the engagement use case, but omits pagination/cursor semantics, date filtering, sorting enums, response contents, and side-effect guarantees. For a 15-parameter tool this is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation of the parameters; schema coverage is effectively zero. Fields like cursor, dateFrom, dateTo, sortBy, and sortDir are left entirely to inference despite having no schema descriptions. The description only hints at time ordering but does not clarify filtering, sorting, or pagination semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'replay one member's raw activity events in time order.' It clearly scopes the tool to a single member rather than a list or aggregate view. It could be a 5 if it explicitly contrasted itself with sibling tools like get_member or list_members, but the resource and purpose are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use to establish when someone last paid attention and what triggered it' gives a concrete use case and an explicit trigger for invoking the tool. It does not mention when to prefer an alternative tool, so it stops short of full usage guidance, but the stated use case is actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for added value is met comfortably: the description reveals the failure mode (unresolved {{tokens}} signal a missing required argument), the default-binding semantics for effective arguments, and the downstream action of calling referenced sm_ tools. This is substantive behavior beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences with no filler: purpose and return value are front-loaded, followed by input source, failure mode, and follow-up action. Every sentence earns its place and each conveys a distinct piece of information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: instruction text, effective arguments with defaults, unresolved-token error signal, and the expected follow-up of invoking referenced tools. Nothing needed to call and chain this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: arguments are bound to prompt placeholders, omitted optionals fall back to defaults, and unresolved tokens indicate a required argument gap. This clarifies how the two parameters interact at runtime.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Render') and resource ('Space Monkey prompt workflow'), and clarifies what is returned: complete instruction text plus effective bound arguments. It also differentiates itself from the sibling family by explicitly naming sm_list_prompts as the source of prompt names, so an agent can tell the two apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes a clear workflow context: prompt names and arguments come from sm_list_prompts, and the rendered output should be followed by calling the sm_ tools it references. This gives strong usage context and routes the agent to the upstream tool, though it stops short of explicit 'when not to use' or exclusion statements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by explaining the dual behavior (index vs. single operation) and the accepted selector formats (tool name, full path, path suffix). It doesn't describe response format details, but with no output schema and a read-only metadata tool, the description carries enough behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. It front-loads the core purpose, then explains the parameter behavior, and ends with a clear usage directive. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only metadata tool with one optional parameter and no output schema, the description is nearly complete. It explains both invocation modes and the accepted selector formats. It doesn't describe the structure of the returned index or operation details, but the description's promise of 'compact index' and 'full parameters and resolved response schemas' gives the agent enough context to call it and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the `operation` parameter thoroughly. The description adds value by summarizing the parameter's behavior in plain language and by clarifying the three accepted selector formats. It doesn't add much beyond the schema, but the baseline for 100% coverage is 3, and the description's summary of the parameter's optionality and selector flexibility earns a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving the Enterprise API's OpenAPI-derived schema catalog. It distinguishes itself from sibling tools by being the meta/schema-discovery tool among the sm_get_* and sm_list_* family, and it explicitly explains the two modes of operation (compact index vs. single operation details).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: 'Use before calling an unfamiliar tool to confirm its exact fields.' It also explains the two usage modes (omit `operation` for index, pass a tool name/path/suffix for details), which is clear guidance for an agent deciding how to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context about what the returned detail contains, which goes beyond the annotations. It does not mention error behavior or auth, but for a read-only detail fetcher this is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The main action and result content are front-loaded, and the usage guidance is placed as a natural second sentence. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple, read-only, two-parameter lookup tool. The description covers what it returns, when to use it, and why it matters. With no output schema present, the description still gives enough return-value context to guide an agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain projectId or runId beyond implying 'one sync run'. The parameter names are somewhat self-explanatory, but the description does not compensate for the missing schema-level parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Load') and resource ('one sync run's full detail'), and enumerates what that detail contains: per-stage results, progress, lookback window, and pending batch count. This clearly distinguishes it from the sibling list tool sm_list_sync_runs and other get tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the prerequisite sibling tool (sm_list_sync_runs) and the exact scenario: use this tool afterwards to explain why data is stale or a run failed. This gives an agent concrete routing guidance with no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what kind of analysis is returned (statistical significance, engagement velocity, geo split), which is useful but not deeply behavioral. It doesn't mention any performance implications, data freshness, or how results are computed, so it's adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the main purpose and lists the report types concisely. The caveat that it's only for multivariate campaigns is placed at the end, which is acceptable. Every sentence contributes value with no redundancy; it's efficient but could be slightly more structured with bullet points.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema and no nested objects, the description covers the analysis scope adequately. However, it doesn't specify the output format or any limitations (e.g., does it work only if there are multiple variants?). The annotations already cover safety, so the description is sufficient for basic use but leaves the exact return value unspecified, which is a gap given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description should compensate for the lack of parameter documentation. However, the description doesn't explain anything about the required parameters (projectId and campaignId) beyond what the schema states. It does not clarify the format of campaignId or whether campaignId refers to a variate campaign ID specially. Given that coverage is 0%, the description fails to add meaningful value for parameter understanding, so a 3 is generous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes A/B campaign reports, listing specific report types (per-variant, statistical significance, engagement velocity, etc.), which distinguishes it from general campaign getters. However, it doesn't explicitly contrast with sibling tools like sm_get_insights_basic or sm_get_insights_expert that might also produce analytical reports, so it's clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes the tool is 'Only meaningful for multivariate campaigns,' which gives a clear condition for when to use it. However, it doesn't explicitly say when not to use it or mention alternatives like sm_get_insights_* that might also handle campaign analysis. The exclusion is narrow and doesn't cover all relevant alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is fully covered. The description adds a useful behavioral nuance about engagementScore being a raw decayed score that can be negative—information not present in annotations or schema. However, it doesn't describe pagination behavior, response format, or any side effects, though these are largely unnecessary given the read-only annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences. The first front-loads the core purpose, and the second adds a critical clarifying note about engagementScore that prevents misinterpretation. Every word serves a purpose with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 13 parameters and no output schema, the description is underspecified. It explains the high-level purpose but omits key operational details like pagination (cursor, pageSize), filtering (botFilter, insiderFilter), rating thresholds (minRating/maxRating), and the meaning of activity windows (minPrior/maxPrior). It also doesn't describe the return fields beyond engagementScore. Given the complexity, the description leaves significant gaps that an agent would need to resolve elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the tool has 13 parameters, so the description bears the full burden of explaining them. The description mentions no parameters at all—it only refers to an output field (engagementScore). While some parameters like 'search' and 'sortBy' are self-explanatory, others like 'maxPrior', 'minPrior', 'cursor', and 'insiderFilter' remain ambiguous. The description fails to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find'), a specific resource ('previously engaged members whose recent activity has collapsed'), and an explicit purpose ('for building save lists'). It also distinguishes itself from sm_list_leaders by noting the engagementScore is raw and can be negative, unlike the leaders percentile. This clearly differentiates it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case ('building save lists') and implicitly signals when this tool is appropriate (when members' activity has decayed). It distinguishes from sm_list_leaders via the score note, but it does not explicitly name alternative tools like sm_list_members or state conditions for not using this tool. Still, the context is clear without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already convey read-only, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds minimal behavioral context by mentioning 'performance metrics' as part of the result, but it does not disclose pagination, cursor handling, or output format beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with the main action and scope front-loaded. The second sentence adds valuable use-case context without redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, no output schema, and no parameter descriptions, the description is not fully complete. It establishes purpose and some use cases, but an agent would still need to infer how cursors, date ranges, search, and volume filters interact, as well as what response shape to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the tool has 10 parameters, so the description must compensate by explaining parameters. It does not mention date filters, cursor semantics, search, sorting directions, or send-volume thresholds; it only implies projectId by saying 'a project's'. This leaves the agent to guess from parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and resource: 'List a project's campaigns with performance metrics.' This clearly communicates plural listing versus sibling getters like sm_get_campaign, and the performance-metric detail narrows the output intent. The added use-case sentence reinforces why the tool is useful without obscuring its core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives two explicit use contexts: mapping a member's lastActivityAt onto a real send and locating the latest house send by send_time. This is practical guidance, though it does not explicitly name alternatives or say when not to use this tool rather than a sibling list tool like sm_get_member_campaigns.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

ReadOnly, idempotent, and non-destructive behavior is already declared by the annotations, so the bar is lower. The description adds the ranking and filtering behavior, but leaves out pagination behavior, cursor semantics, open-ended result expectations implied by openWorldHint, and default filtering like leaderOnly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, front-loads the action and outcome, and provides the most relevant filtering context in a compact form. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 16-parameter surface and no output schema, the description is under-complete. It does not describe return shape, pagination (cursor/pageSize), how scoring limits work, or the default leaderOnly filter, leaving an agent to inspect the schema or discover behavior at runtime.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for explaining 16 parameters. It only sketches a few filter dimensions (rep, tag, rating, status, bot/insider) and omits or leaves ambiguous the meaning of minScore/maxScore, search, cursor, pageSize, and the default leaderOnly behavior. This is not enough to compensate for the lack of individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Rank'), a precise resource ('the most engaged members of a project'), and the ranking basis ('by engagement percentile'). It also differentiates itself from sibling list tools by emphasizing leadership/engagement and the filtering dimensions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit use case ('Use when you need who is paying attention right now') and lists relevant filter axes. However, it does not explicitly contrast this with sibling tools like sm_list_members or sm_list_at_risk, so the 'when not to use' guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The read-only, idempotent, non-destructive behavior is already disclosed by annotations, lowering the description's burden. The description does add that this covers the full directory and supports search/filtering, but it does not disclose pagination behavior, response scaling, or other execution nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely efficient: two sentences, no filler, front-loaded action and followed by a 'when to use' sentence. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 20-parameter schema with no per-parameter descriptions and no output schema, this description is too sparse to fully support correct invocation. It does not cover pagination, sorting, filter combinations, or the meaning of the many specialized filters, even though this is a complex list/search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description correctly maps the user intention to parameter categories like rating, tag, status, and free-text search. However, it leaves many parameters unexplained, including cursor, pageSize, sortBy, sortDir, region, leader, botFilter, insiderFilter, and the dimension filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly names a concrete verb-resource pair ('Browse or search a project's full member directory') and gives a specific differentiating set of dimensions: rating, tag, status, and free-text search. This clearly distinguishes the tool from the engagement-rank-oriented sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains an explicit 'Use when...' clause and a negative hint: 'rather than by engagement rank.' However, it never names the sibling alternative(s), such as sm_list_leaders, so an agent is not fully routed to the correct alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context: the matching behavior on companyName and the caution not to silently mix projects. It also reveals that results depend on the API key's permissions. This goes beyond annotations, though it does not describe return format or pagination, which are reasonable gaps for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence front-loads the primary purpose, and the second provides usage guidance and a caution. Every word adds value; the structure is optimal for agent comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-argument, no-output-schema tool, the description provides all necessary context: what it returns, when to use it, and a behavioral constraint. It is complete enough for an agent to know when and how to call it without ambiguity. The lack of pagination or return-format details is not a gap given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to explain any. The baseline for zero parameters is 4, and the description adds no parameter-specific details but does not need to. It implicitly explains how the tool behaves (matching on companyName), which is contextually relevant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Resolve which Space Monkey projects this API key can read.' It specifies the resource (projects) and the scope (readable by API key). It also distinguishes itself from sibling list tools by focusing on projects and the companyName matching behavior, which is a unique identifier. No confusion with other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Call this first when the user names a company rather than a project ID.' It contrasts with project IDs, implying that for project IDs a different tool would be used. However, it does not name the alternative tool, leaving some inference to the agent. The 'never silently mix projects' rule further clarifies safe usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds context about what an entry contains (arguments and category) and what prompt workflows are, which is useful beyond the annotations. It does not over-explain behavior already declared structurally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The opening states the core action, the parenthetical gives concrete examples, and the second sentence explains output contents and the next step. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only list tool with no output schema, the description explains what the response contains, gives workflow examples, and points to the follow-up action. It is sufficient for an agent to call and interpret results correctly, though it could name the category/argument fields more explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and 100% coverage, so parameter documentation is unnecessary. The baseline for no parameters is 4, and the description adds relevant context about the output entries instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('Space Monkey prompt workflows'), and expands on what these are: user-invocable recipes that chain sm_ tools into sales actions. It also points to sm_get_prompt as the related rendering tool, helping distinguish list from get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly establishes when to use this tool: to discover available prompt workflows and their arguments/categories. It explicitly tells the agent to use sm_get_prompt to render one with concrete argument values, but does not mention any exclusions or alternative list tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds that results are limited to 'recent' runs and include status/results, but it does not disclose pagination behavior, ordering, or how many runs are returned. Vague on what 'recent' means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action and resource, and adds only the useful operational context about data freshness. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple list tool, annotations covering read-only/idempotent behavior, and schema exposing pagination parameters, the description covers the core need: what it lists and why you would use it. It does not explicitly route to sm_get_sync_run, but the plural 'list' and 'recent' scope make the intent sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is effectively zero)Skip; the description does not compensate by explaining the required projectId scoping or the meaning of cursor/pageSize. The names are self-explanatory, but an agent still receives no guidance on pagination or required parameters beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List'), a clear resource ('sync runs'), and scope ('recent', 'status and results'). The plural 'runs' plus the distinction from the singular sm_get_sync_run sibling makes the tool's purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'checking data freshness before trusting an analysis' provides a clear operational context for when to call this tool. However, it does not explicitly contrast with sm_get_sync_run or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.