paid-media-mcp

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation3/5
Most tools have distinct purposes, but multiple tools with similar names (e.g., get_campaign_performance, get_campaign_performance_report, get_campaign_performance_metrics, get_daily_performance) could cause confusion for an agent. Detailed descriptions help, but the overlap in naming reduces clarity.
Naming Consistency5/5
All tool names follow snake_case with a consistent verb_noun pattern (e.g., get_team, list_campaigns, reallocate_media_budget). There is no mixing of conventions or chaotic naming.
Tool Count2/5
With 73 tools, this is far beyond the typical range for an MCP server. While the domain is broad, this many tools can overwhelm agents and suggests insufficient scoping or granularity.
Completeness4/5
The tool set covers an extensive range of paid media operations: campaign management, attribution, identity signals, data quality, audience, and reporting. Minor gaps exist (e.g., lack of create/update for some entities), but the core analytical and operational workflows are well-covered.
Average 3.7/5 across 73 of 73 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It describes a read operation ('Get') but does not disclose any behavioral traits such as authentication requirements, rate limits, data freshness, or side effects. The description is too terse to inform the agent about safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, which is concise, but it lacks crucial information such as parameter details and usage context. It sacrifices completeness for brevity, making it insufficiently informative for an agent. The structure is simple but not well-calibrated to the tool's needs.
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 has 1 parameter and no output schema, the description should fully explain the input and output. It fails to describe the return format of the instructions, does not clarify that the platform must be selected from the enum, and provides no context about the bulk upload process. The description is incomplete and relies on the agent's prior knowledge.
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% for the single parameter 'platform'. The description does not mention the parameter at all, despite it being required and an enum. It only vaguely references 'a GMP platform', failing to add meaning beyond the schema's enum values. This leaves the agent without guidance on how to fill the parameter.
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 identifies the tool's purpose: to retrieve step-by-step upload instructions and file naming requirements for a GMP platform's bulk upload format. The verb 'Get' and the specific resource 'upload instructions' make the action and object clear. However, it does not distinguish from the sibling tool 'get_bulk_upload_schema', which could be confused as providing similar schema information.
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 'get_bulk_upload_schema' or 'list_bulk_upload_platforms'. There is no mention of prerequisites, context, or conditions under which this tool should be invoked.
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?
Without annotations, the description carries the full burden of behavioral disclosure. It indicates the tool returns data and is likely read-only, but it does not mention any side effects, rate limits, or permission requirements. The description is minimal for a data retrieval 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 extremely concise with two sentences. The first sentence front-loads the verb and resource, and the second provides key details about the output. There is no superfluous information.
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 of the sibling tools and lack of output schema, the description is moderately complete. It explains what the tool returns but does not differentiate from similar tools or provide enough detail about parameter usage. It adequately covers basic functionality but has 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?
Only one of three parameters (campaign_id) has a description in the schema. The description mentions 'date range' but does not explicitly link to date_from and date_to. It adds some context about the output format (per-day records and aggregates) but fails to explain parameter semantics or valid formats for dates.
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 'Get' and the resource 'historical performance data for a campaign'. It also specifies the return format with per-day records and aggregated totals, making the purpose well-defined. However, it does not explicitly differentiate from sibling tools like get_campaign_performance_report, which could cause ambiguity.
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 such as get_campaign_performance_report or get_campaign_performance_metrics. There is no mention of prerequisites or exclusions, leaving the agent to infer the appropriate context.
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, the description carries full burden. It clearly states the tool returns live data from BigQuery, lists the metrics returned, and highlights that three ROAS numbers are shown side-by-side. This is good transparency for a read-only report, though it omits any mention of authentication or rate limits.
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 two concise sentences, front-loaded with the core purpose. Every clause adds value with no redundancy or fluff.
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 6 parameters with zero schema descriptions and no output schema, the description is incomplete. It explains the output but leaves agents without critical information on how to invoke the tool correctly.
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%, and the description provides no explanation for any of the 6 parameters (status, dates, team_id, platform, funnel_stage). The agent cannot infer parameter meanings from the current text.
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 queries live campaign performance from BigQuery and lists specific metrics returned. However, it does not explicitly differentiate from similar sibling tools like get_campaign_performance or get_campaign_performance_metrics, so it stops short of a 5.
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 a prerequisite ('Requires BigQuery mode') but provides no guidance on when to use this tool versus alternatives, nor any exclusion criteria. This is minimal usage 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 provided, so description carries full burden. Discloses requirement for BigQuery mode and lists return metrics. However, does not mention whether it is read-only, potential side effects, latency, or rate limits. Partial 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?
Description is concise with three sentences, front-loaded with purpose and scope. No superfluous information. Could benefit from more structured formatting for parameters, but overall efficient.
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 6 parameters, no output schema, and many sibling tools, the description is incomplete. Does not describe output format structure, parameter details, ordering, or pagination. Required BigQuery mode noted, but insufficient for full operational understanding.
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 has 0% description coverage. Description only partially explains 'group_by' via mention of aggregation by week or month. Other parameters (date_to, team_id, platform, date_from, campaign_id) remain unexplained, adding minimal value beyond the schema's type/enum constraints.
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?
Description clearly states it returns daily performance time series across all campaigns, listing specific metrics and aggregation options. Differentiates from sibling tools like get_campaign_performance by emphasizing 'all campaigns', but could more explicitly distinguish from similar performance tools.
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?
Provides explicit use cases: trend analysis, anomaly detection, week-over-week/month-over-month reporting. However, lacks guidance on when not to use this tool (e.g., for single campaign analysis where get_campaign_performance might be better) and no alternatives mentioned.
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 provided; description lists returned fields (status, platforms, cadence, contacts) but doesn't disclose read-only nature, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, but could be more structured with bullet points.
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?
Adequate for a simple list tool with one optional parameter and no output schema, but missing parameter description limits completeness.
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?
Description does not mention the 'type' parameter at all, despite 0% schema description coverage. The parameter is an enum for filtering, but no guidance on its use.
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?
Description clearly states the action (List) and resource (measurement and analytics partners), with specific examples. Distinct from sibling tools like list_attribution_models or get_measurement_overview.
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 on when to use this tool vs. alternatives, no prerequisites, and no exclusions provided.
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, and the description does not disclose whether the tool mutates any data, requires specific permissions, or handles missing template_id. It only implies a read-like operation but lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no extraneous information. Every sentence adds value.
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?
With no output schema and 5 parameters, the description is too sparse. It does not explain the output format, behavior when template_id is omitted, or how it differs from similar report tools.
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 coverage is 60%, but only date parameters have descriptions. The description adds context for target_type (campaign/team) and template_id (reporting template), but does not fully compensate for undocumented parameters like target_id.
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 generates a narrative report for a campaign or team, combining live data with a template. This distinguishes it from sibling tools that only retrieve raw performance data.
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?
It suggests using a reporting template ID for the intended audience, but does not explicitly state when to use this tool versus alternatives like get_campaign_performance_report or get_team_performance.
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 bears full responsibility. It details the output fields and thresholds, which adds transparency. However, it does not disclose auth requirements, rate limits, data freshness, or any side effects. The behavior is adequately described for a read-only report.
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 with the purpose. It then lists output fields, thresholds, sorting order, and the BigQuery requirement. Every sentence adds value, and the structure is logical. Minor improvement could be achieved with bullet points.
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 absence of output schema and annotations, the description should provide comprehensive guidance. While it explains the output well, it fails to describe the input parameters. The tool has 4 parameters, all undocumented, making it incomplete for effective 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 coverage is 0%, meaning the description does not explain any of the 4 parameters: team_id, platform, funnel_stage, pacing_status. Despite the schema having enums for two parameters, the description offers no guidance on how to use these filters. This is a critical gap.
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 returns budget pacing status for campaigns that have started flying. It specifies the metrics: expected vs actual spend, required daily spend, projected total spend, and a pacing_status label. It also explains the thresholds for over/under pacing and sorting order, distinguishing it from sibling tools like get_monthly_budget_pacing.
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 mentions a prerequisite: 'Requires BigQuery mode.' However, it does not provide explicit guidance on when to use this tool versus alternatives like get_monthly_budget_pacing or get_campaign_performance. The usage context is implied but not exclusive.
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 a read-centric behavior (summarize completed tests) but does not disclose any side effects, authentication needs, or data freshness. The description is adequate but lacks depth on potential limitations or assumptions.
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, well-structured sentence that front-loads the purpose and key details. It is concise and informative, though the lack of parameter descriptions slightly reduces efficiency for an agent.
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?
With no output schema and 3 optional parameters with enums, the description is incomplete. It does not explain how parameters affect results or describe the return structure. For a tool that can filter by type and platform, this omission limits usability.
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?
The schema has 0% description coverage, and the tool description does not explain any of the three parameters (type, team_id, platform). Despite having enums, the agent receives no guidance on how to filter results or what each parameter does. This is a critical gap.
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 that the tool summarizes completed test results, specifying the attributes covered (what was tested, winning variant, lift, statistical significance, action taken) and the scope (in-campaign A/B tests and vendor/partner evaluations). This differentiates it from siblings like get_test (focused on a single test) and list_tests (listing tests).
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 clear context on what the tool covers but does not explicitly state when to use this tool over alternatives (e.g., list_tests for a list of all tests, get_test for detailed results of a specific test). No exclusion criteria 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, the description carries full burden for behavioral disclosure. It fails to mention pagination, result limits, ordering, or whether the tool returns full details or summaries. The 'list' verb implies read-only, but no safety or performance traits are described.
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 sentence (17 words) with front-loaded intent and parenthetical examples. Every word adds value, no redundant or irrelevant information.
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 no output schema and no annotations, the description should at least hint at the return structure (e.g., audience IDs, names, sizes). It does not. For a tool with two optional parameters, the description covers basics but leaves significant gaps in what the agent needs to know.
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 states that parameters are filters for 'business unit or platform availability', but does not specify format or allowed values for business_unit, nor that platform is an enum. It adds general context but lacks precise semantics.
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 verb 'List' and the resource 'first-party audiences' with concrete examples (CRM lists, pixel-based, etc.). This distinguishes it from sibling tools like list_third_party_audience_layers, making it unambiguous.
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 such as get_audience_library_overview or list_third_party_audience_layers. The description only mentions filtering options but lacks explicit when-to-use or when-not-to-use instructions.
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 provided, so description carries full burden. It lists returned fields but omits behavior details like permission requirements, sorting order, what 'recent' means, pagination, and handling of empty results.
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?
Two concise sentences: first defines the resource and fields, second provides usage advice. No unnecessary words, front-loaded with key information.
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?
For a simple tool with one optional param and no output schema, the description misses important details: explanation of the limit parameter, default behavior, sort order, and what constitutes 'recent.' Agent would lack info to call it correctly.
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?
The only parameter 'limit' (number, optional) is not mentioned in the description at all. Schema description coverage is 0%, so agent gets no guidance on what this parameter does.
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?
Description clearly states it lists recent attribution model runs and specifies the fields returned (model used, date range, etc.). It distinguishes from sibling tools like list_attribution_models which list models, not runs.
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?
Explicitly tells when to use: 'check when the model last ran, whether it succeeded, and whether a new run is needed.' Does not mention alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 comparison but does not state whether the tool is read-only, if it requires any special permissions, what the output contains, or any side effects. This is insufficient for a tool with no 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 a single sentence that is front-loaded with the core action and outcome. No redundant words or unnecessary details are present; every part serves the purpose.
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 absence of an output schema, the description should at least hint at the return format (e.g., side-by-side comparison table, list of differences). It only mentions what aspects are compared but not how results are presented. For a simple tool with two parameters, this lack of output context leaves the agent guessing.
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 descriptions already cover both parameters (attribution_id_a, attribution_id_b) fully, achieving 100% coverage. The description adds value by specifying the aspects compared (model type, windows, conversion events, use cases), but this is marginal and does not significantly enhance parameter understanding beyond 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: comparing two attribution configurations side-by-side to understand differences in model type, windows, conversion events, and use cases. It uses a specific verb ('compare') and resource ('attribution configurations'), effectively distinguishing it from siblings like get_attribution_model or list_attribution_models.
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 a user wants to understand differences between two configurations, but it does not explicitly state when to use this tool versus alternatives (e.g., get_attribution_model for a single model). No exclusion criteria or context for decision-making is provided.
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 provided, so description must cover behavioral traits. It only states what info is returned, omitting safety, auth needs, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with action and result, listing details efficiently.
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 no output schema, the description lists core returned details. Could mention response structure or additional fields, but adequate for a simple retrieval.
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 covers the single parameter at 100%, so baseline 3. Description adds no extra meaning for the parameter itself beyond the schema's 'Asset category ID'.
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 explicitly states the verb 'Get' and the resource 'asset category', listing specific details returned (location URL, naming convention, per-platform specs). This clearly distinguishes it from sibling tools like 'list_asset_categories'.
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 on when to use this tool versus alternatives. No mention of prerequisites or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'get full details' without explaining what 'full details' includes, authentication needs, or rate limits. The description is too minimal.
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?
Single, well-structured sentence that is front-loaded with the key action and resource. No unnecessary words.
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?
For a simple single-parameter GET tool with no output schema, the description is mostly adequate. It could be improved by hinting at the response structure (e.g., 'returns all campaign fields').
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 100%, so baseline is 3. The description adds 'by its ID' which aligns with the schema but does not provide additional semantic value beyond what the schema already states.
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 uses a specific verb ('get full details') and clearly identifies the resource ('single campaign'). It distinguishes itself from siblings like 'list_campaigns' (which lists multiple campaigns) and other 'get_*' tools for different resources.
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 on when to use this tool versus alternatives (e.g., list_campaigns for browsing, or other get tools). The description does not 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.
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 operation as a read that returns specific data fields, and it reveals the technical requirement of BigQuery mode. It does not disclose any limitations, rate limits, or data freshness, which would be beneficial for 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 concise with two sentences that front-load the main action and data points. It avoids unnecessary details and gets to the point 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 complexity of the data (multiple metrics across time periods) and the lack of an output schema, the description should clarify the return structure. While it lists data points, it does not indicate if the output is a time series or aggregated, and it does not explain the relationship between the lookback_days parameter and the timeframes mentioned. The tool has only 2 parameters, so the description could be more 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?
The input schema has parameter descriptions for 'company_domain' but none for 'lookback_days'. The tool description mentions timeframes but does not explicitly link them to the 'lookback_days' parameter or explain how it controls the output. This leaves the optional parameter's role ambiguous.
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 it returns daily activity history for a specific target account and lists the specific data points included. However, it does not explicitly differentiate itself from sibling tools like get_target_account_funnel or get_company_engagement, so the purpose is clear but sibling differentiation is implicit.
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 explicitly recommends using this tool for building engagement charts or briefing sales reps, and it notes the prerequisite of BigQuery mode. It does not provide guidance on when not to use it or alternatives, but the use cases given are clear.
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 exist, so the description must carry the full burden. It implies a read-only list operation but does not explicitly state safety, authentication needs, or side effects. No destructive or rate-limit info is provided.
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 minimal and front-loaded: two sentences covering purpose, examples, returned fields, and filtering. No superfluous words.
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?
For a simple list tool with one optional parameter and no output schema, the description covers the key aspects: what is listed (conversion API implementations) and the data fields (events, match rate, dedup method). It could mention pagination or what happens with no filter, but overall it is quite complete.
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 only parameter, 'platform', lacks a schema description (0% coverage). The description adds that it filters by platform, which gives some meaning, but does not explain default behavior (e.g., if omitted, returns all) or the impact of each enum value.
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 identifies the verb (list), the resource (Conversion API implementations), and the scope (all, with examples). It also distinguishes the tool from siblings like list_pixels_and_tags by specifying the domain (conversion APIs with specific platforms).
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 does not provide guidance on when to use this tool versus alternatives like list_pixels_and_tags or get_website_data_capture. No explicit when/when-not or alternative references are given.
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?
The description indicates it is a listing operation and discloses some output fields. With no annotations provided, it carries the full burden but lacks details on pagination, permissions, or whether the list is complete. Adequate but not thorough.
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?
A single, front-loaded sentence that efficiently conveys the action and key details without extraneous words.
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?
For a simple list tool with one optional parameter, the description is mostly adequate but misses details on return format, pagination, and how it compares to sibling tools like get_tag_management.
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 meaning to the platform parameter by stating it is an optional filter. Since schema coverage is 0%, this adds value beyond the schema enum, though it does not explain the effect of omitting the parameter.
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 it lists all platform pixels and tracking tags and specifies the information returned (implementation type, events, custom parameters). However, it does not explicitly distinguish itself from similar siblings like get_tag_management.
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 an optional filter by platform but provides no guidance on when to use this tool versus alternatives, nor any 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 provided, so the description must fully convey behavioral traits. It indicates a read operation but omits details about idempotency, rate limits, or response structure beyond the examples given.
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. Could be slightly improved by front-loading the primary purpose.
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?
For a simple get tool with one parameter and no output schema, the description adequately covers the purpose and key details. It could mention error handling or permissions, but is sufficient for basic 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 coverage is 100% for the single parameter, but the description adds minimal context about what the parameter represents beyond 'The account ID'. The main value is in describing the output rather than the parameter.
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 it retrieves details for a specific ad account, including team management and budget. This distinguishes it from sibling tools like list_accounts (which lists all) or get_team_for_account (which focuses only on team).
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?
No explicit guidance on when to use this tool vs alternatives. It implicitly contrasts with siblings, but no 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses the return fields and a prerequisite (BigQuery mode). However, it omits behavioral traits like whether it's read-only, required permissions, rate limits, or error conditions. It is adequate but not comprehensive.
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?
Three sentences, front-loaded with purpose, then return fields, then usage and prerequisite. No fluff or repetition. Every sentence earns its place.
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 4 undocumented parameters and no output schema, the description is insufficient. It explains output but fails to guide parameter usage. For an agent to use this tool correctly, far more parameter context is needed.
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?
The input schema has 4 parameters with 0% description coverage, and the tool description provides no explanation of the parameters (platform, min_spend, campaign_id, creative_format). The agent has no guidance on valid values or formats, severely hindering correct invocation.
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 returns 'Ad/creative level performance with multi-touch attribution credit' and lists specific metrics. This precisely distinguishes it from sibling tools like get_campaign_performance (campaign-level) and get_keyword_performance (keyword-level).
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?
It provides explicit usage guidance: 'Use to identify winning creatives for scaling and underperforming ones to pause or rotate.' It also notes the prerequisite 'Requires BigQuery mode.' However, it does not specify when not to use it or mention alternatives.
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, and the description offers no behavioral context beyond stating it retrieves details. It does not disclose read-only nature, permissions needed, potential errors, or side effects, leaving a significant gap for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that lists key return elements. It is front-loaded and contains no extraneous information, though a slightly more structured format (e.g., bullet points) could improve readability.
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?
For a simple tool with one parameter and no output schema, the description sufficiently covers what the tool returns. It lacks mention of error states or authentication, but given low complexity, it is largely complete.
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 coverage is 100% (description for attribution_id), and the description does not add extra meaning beyond what the schema already provides. The parameter's purpose is clear from the schema, so the description is adequate but not enhanced.
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 retrieves full details of a specific attribution configuration and enumerates the included components (model, window, conversion events, cross-device settings, intended use cases), distinguishing it from sibling tools like list_attribution_models and compare_attribution_models.
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 does not explicitly provide when to use this tool versus alternatives. Usage is implied from the context of sibling tools (e.g., having a specific ID vs. listing), but no direct guidance or exclusions are stated.
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 provided, so description carries full burden. It discloses the BigQuery prerequisite and return metric, but does not declare read-only nature or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, output, use case, and requirement. No wasted words.
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 3 undocumented parameters and no output schema, the description lacks details on parameter semantics and return structure. Incomplete for a tool with these gaps.
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 has 3 string parameters with 0% description coverage. The description does not explain their meaning, accepted values, or constraints. Fails to compensate for lack of schema descriptions.
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 it compares three ROAS metrics per channel, returns platform_overcount_pct, and specifies its use case. It is distinct from sibling tools like get_attribution_results or get_channel_efficiency.
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?
Explicitly says to use for quantifying attribution inflation and budget decisions, and notes BigQuery mode requirement. Does not mention when not to use or list alternatives.
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 must carry the full burden. It only states the action ('list') without disclosing behavioral traits like read-only nature, pagination, rate limits, or any side effects. Minimal 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 sentence with no wasted words. It is front-loaded with the primary action and includes the optional filter concisely. Every part earns its place.
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 simplicity (one optional param, no output schema), the description is adequate but not complete. It lacks information about return fields, pagination, or any limits. For a list tool, the agent would benefit from knowing what data is returned.
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 schema has one optional parameter (team_id) with 0% coverage. The description adds 'optionally filtered by team,' clarifying the parameter's purpose beyond the schema's type-only definition. It could be more specific (e.g., format or examples), but it adds meaningful semantic context.
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?
Description clearly states 'List all ad accounts, optionally filtered by team.' It specifies the verb (list), the resource (ad accounts), and the optional filter. This is specific and distinguishes from sibling tools like list_teams and get_account.
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 on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites, or comparisons to siblings. The agent is left without context for selection.
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, the description carries full burden for behavioral transparency. It correctly implies a read-only operation but fails to disclose details like what parameters are required or the structure of the returned 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 sentence that front-loads the essential information (what is retrieved and for what purpose). Every word adds value and there is no waste.
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 two enum parameters with no required fields and no output schema, the description is somewhat incomplete. It does not explain the output format or default behavior (e.g., when no filters are applied), but the core purpose is conveyed.
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% and the description does not explain the purpose of the two parameters (platform and objective). The enum values provide some context, but the description adds no additional meaning beyond 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 verb 'Get' and the resource 'industry/platform benchmarks', explicitly listing the key metrics (CTR, CPC, CPM, CPA, ROAS). It distinguishes itself from siblings like get_campaign_performance by specifying it returns benchmarks for comparison.
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 gives implied usage context by stating 'to compare against actual performance', but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools.
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, the description effectively discloses behavioral traits: no raw IP storage, /24 prefix resolution, and BigQuery requirement. It also lists returned fields. Missing details like pagination or rate limits, but the key constraints are covered.
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?
Three well-structured sentences: first states purpose and output, second lists included fields, third adds important constraints. No filler; every sentence adds value.
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?
The description covers return fields, IP handling, and a prerequisite. Without an output schema, it adequately explains what sessions contain. However, missing default lookback, pagination, or ordering could hinder usage in complex scenarios.
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 50% (only company_domain documented). The description adds no specific meaning for lookback_days (e.g., default, range) and repeats the domain concept without enhancing it. More detail is needed to compensate 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 returns de-anonymized web sessions for a specific company, listing included fields. However, it does not explicitly differentiate from sibling tools like get_website_data_capture, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying sessions by company domain over a lookback window and notes a prerequisite (BigQuery mode), but offers no guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as read-only nature, required permissions, rate limits, or side effects. The tool name implies a read operation, but the description fails to confirm or add 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 consists of two concise sentences. The first sentence defines the purpose, and the second provides usage guidance. No unnecessary words or repetition. Every sentence adds value.
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 there is no output schema, the description could have provided more details about the returned defaults (e.g., structure or examples). It mentions 'default field values and naming conventions' but does not elaborate, leaving some ambiguity about the output format.
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 one parameter 'platform' with enum values but no descriptions. Schema description coverage is 0%. The description does not add any information about the parameter or its values, so the agent gains no additional meaning beyond the raw 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 it retrieves 'org-configured default field values and naming conventions for a platform's entity types'. The verb 'get' and resource 'defaults for platform' are specific. It also distinguishes from siblings by linking to bulk upload generation.
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 explicitly says 'Use this when generating bulk upload files to apply the team's standard settings', providing clear context for when to invoke the tool. However, it does not mention when not to use it or list alternative tools.
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, and the description only states the tool lists configurations. It does not disclose behavioral traits such as read-only nature, required authentication, or potential side effects, leaving the agent uninformed.
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, well-structured sentence that includes specific details about the tool's output, earning its place 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?
The description outlines the key return fields (model type, windows, conversion events, platforms) despite no output schema. It is fairly complete for a list tool, though it could hint at structure or pagination.
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 0 parameters with 100% coverage, so the description need not add parameter semantics. The baseline of 3 is appropriate.
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 lists all attribution configurations, specifying included details like model type, windows, conversion events, and platforms. This distinguishes it from siblings like get_attribution_model (singular) and compare_attribution_models.
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 for retrieving team-level attribution configs, but lacks explicit guidance on when to use this versus alternatives (e.g., get_attribution_model for a specific model). No when-not or exclusion criteria are provided.
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 bears full responsibility. It fails to disclose whether the operation is read-only or if any permissions are required, nor does it mention any side effects or rate limits. The description only states what is returned.
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 two sentences, front-loaded with the primary purpose, and includes actionable guidance on filtering. Every sentence contributes value with no redundancy.
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 no output schema and minimal annotations, the description adequately states the tool's return content and filter options. However, it lacks details on pagination, return format, or required access, leaving some gaps for a tool with three parameters.
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 description mentions filtering by priority or status, which maps to two enum parameters, adding meaning beyond the bare schema. However, the 'limit' parameter is not described, and with 0% schema description coverage, the description only partially compensates.
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 retrieves insights and recommendations from the Analyst agent, listing specific types such as channel anomalies and incrementality signals. This differentiates it from sibling tools like get_campaign_performance or get_benchmarks, which focus on different data.
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 advises filtering by priority or status to focus on urgent items, providing clear usage context. However, it lacks explicit guidance on when to prefer this tool over alternatives, though no direct competitor exists among siblings.
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 provided, so the description carries full burden. It discloses the tool returns specs but omits behavioral traits like idempotency, side effects (none expected), or authentication requirements. It is adequate but minimal.
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?
Single sentence, directly to the point, front-loaded with the key action and result. No wasted words.
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?
No output schema, so the description helpfully lists the kinds of specs returned (dimensions, file size, etc.). It covers the core functionality but could add more about response structure or any limitations (e.g., only returns for supported combinations).
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 coverage is 0%, and the description does not add meaning to the enum values for 'type' or 'platform'. It mentions 'given asset type and platform combination' but does not list or explain the accepted values, leaving the agent without needed context.
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 retrieves platform-specific asset specs (dimensions, file size, aspect ratio, duration limits) for a given asset type and platform combination, differentiating it from sibling tools like get_asset_library or list_asset_categories.
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 the tool is used to look up specs for a type/platform combination but offers no explicit guidance on when to use it versus alternatives or 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.
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. It discloses key behavioral traits: always scoped to current month, no date filter, 150-row cap, and required environment variables. It also explains the meaning of several output fields. This gives an agent good awareness of the tool's behavior, though it could mention whether results are sorted or if pagination exists.
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 a concise opening sentence followed by bullet-pointed key fields. It is informative without being verbose. However, it could be slightly more concise by omitting the full bullet list and referring to the schema for field details (though no output schema exists). Overall, it earns its length.
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 simplicity (optional params, read-only, no output schema), the description provides constraints, environment requirements, and field meanings. However, it does not specify the return shape (e.g., list of objects), how parameters affect the result, or error conditions. It is adequate but not fully complete for an agent to anticipate all outcomes.
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 clarify parameters. It mentions 'all active campaigns' but does not explain the optional 'platform' and 'campaign_id' parameters or how they filter results. Without this, an agent cannot reliably use them. The description adds minimal semantic value beyond 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 retrieves current calendar-month pacing status for all active campaigns from a specific BigQuery view. It lists key output fields, making the purpose specific and actionable. Though it does not explicitly differentiate from siblings like 'get_pacing_report', the detail and scope are sufficient for a clear purpose.
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 notes that the view is scoped to the current month with no date filter and requires specific environment variables. However, it does not provide guidance on when not to use this tool versus alternatives (e.g., other reporting tools) or indicate prerequisites beyond environment setup. Usage guidelines are implied but not explicit.
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 provided, so the description must carry the burden. It clarifies it returns details (read operation) but does not disclose permissions, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficiently listing key attributes. Front-loaded with the verb 'Get'. No wasted words.
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 no output schema, the description adequately covers what the tool returns (platform, container ID, etc.). It is complete for a simple retrieval tool.
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?
No parameters exist, so the baseline is 4. The description adds value by listing the returned fields, which provides context beyond the empty 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 it retrieves tag management system details, listing specific attributes. It distinguishes from sibling tools like get_cm360_setup or list_pixels_and_tags, which cover different aspects.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions.
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, the description correctly implies a read-only lookup operation. No hidden side effects are indicated, which is acceptable for a simple retrieval tool. However, it could disclose more about permissions or error cases.
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 that conveys the core action efficiently. Every word is necessary, and there is no extraneous content.
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?
For a simple lookup with one parameter, the description captures the essence. However, without an output schema, mentioning what the response contains (e.g., team ID, team name) would improve completeness.
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 description adds no meaning beyond the schema; 'account_id' is already described as 'The ad account ID' in the schema. The description merely restates the concept without clarifying format, constraints, or usage.
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 'Look up which team owns a given ad account' clearly states the verb (look up), resource (team ownership for an ad account), and distinguishes it from siblings like 'get_team' (team details) and 'list_teams' (all teams). The mapping from account to team is unique.
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 when-to-use or when-not-to-use guidance is provided. There are no alternatives mentioned, and the description does not help an agent decide between this and other tools like 'get_team' for retrieving team details.
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 must cover behavioral traits. It does not describe what 'full details' includes, error handling, permissions, or return format. For a simple get-by-id, more context is needed.
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 sentence with no wasted words, immediately conveying purpose and key parameter role.
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?
For a simple get-by-id tool with one parameter and no output schema, the description is functional but lacks details on return values and error states. It is adequate but has 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 100% (the param already says 'The team member ID'). The description adds minimal value beyond 'by ID', so baseline 3 applies.
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 'Get full details for a single team member by ID' uses a specific verb ('Get'), resource ('team member'), and scope ('single', 'by ID'), clearly distinguishing it from sibling tools like list_team_members or get_team.
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 when you have a specific member ID and need full details, contrasting with list_team_members for listing. However, it does not explicitly state when not to use it or mention alternatives.
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, and the description does not disclose behavioral traits such as read-only nature, required permissions, or side effects. Given that the tool is a retrieval operation, some transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely lists the methodology components. It is front-loaded with the action, though formatting could be slightly improved with bullet points for clarity.
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 no parameters and no output schema, the description provides a reasonable overview of what the tool returns. However, it lacks details on output structure, per-team scope, or data source, which could be useful for complete context.
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 zero parameters, so the schema coverage is effectively 100%. Per guidelines, baseline is 4 since no parameter documentation is needed.
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 retrieves the team's testing methodology, listing specific components like confidence threshold and minimum sample size. This distinguishes it from sibling tools, as no other tool mentions methodology.
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 indicates what the tool returns but does not specify when to use it versus alternatives, nor does it provide exclusions or prerequisites. Usage is implied but not explicit.
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 full burden. It discloses that the tool shows contract status, segments, platforms, and contact info, but does not mention whether it is read-only, any authentication requirements, data freshness, or pagination.
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 two sentences, front-loaded with the action and examples, and contains no redundant information. Every word earns its place.
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?
For a simple list tool with one optional enum parameter, the description covers purpose and output fields well. It could mention that the output is a list or note any pagination limits, but given the lack of complexity, it is largely 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?
The single optional parameter (status) is self-explanatory from its enum values, but schema description coverage is 0%, and the description does not mention the parameter or how it filters results. The description fails to add value beyond 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 uses the specific verb 'List' and resource 'contracted third-party data providers', citing concrete examples (Oracle Data Cloud, Acxiom, Experian). It clearly distinguishes from sibling tools like list_measurement_partners or list_first_party_audiences.
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 this tool is for viewing third-party provider contracts, but it does not explicitly state when to use it vs. alternatives like list_measurement_partners or list_third_party_audience_layers. No exclusions or conditions are provided.
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 provided, so description carries full burden. It does not disclose pagination, ordering, auth requirements, or limits. Only states what the tool lists, not how it behaves.
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?
Two short sentences, no filler, front-loaded with purpose. Every word earns its place.
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?
Relatively complete for a simple list tool with one optional param. Lacks info on response format, pagination, or field set. Not fully thorough but minimally viable.
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?
One optional parameter (team_id) with 0% schema coverage. Description adds 'optionally filter by team', which clarifies its purpose, but no format or valid values.
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?
Clearly states verb 'List' and resource 'team members' with attributes (roles, platform specialties, responsibilities). Distinguishes from sibling get_team_member (singular) and list_teams.
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?
Mentions optional filter by team, indicating a key usage scenario. However, no explicit guidance on when to use this vs. get_team_member or other list 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, the description carries the full burden. It discloses that the tool queries BigQuery, returns chronological touchpoints with attribution weights, and requires an environment variable. However, it does not mention side effects, rate limits, data freshness, or read-only nature explicitly. More detail would be beneficial.
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 (~60 words) and front-loaded with the core purpose. Every sentence adds value, though the information could be better structured (e.g., separated into prerequisites and 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's complexity (3 parameters, no output schema, no annotations), the description explains the return type (multi-touch attribution path with touchpoints and weights) and the requirement for BigQuery mode. However, it lacks details on output format, pagination, performance, or maximum results.
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 only 33% (only account_domain has a description). The tool description adds no additional parameter details. Two parameters (lookback_days, conversion_type) are left without any explanation in the description, relying solely on the schema's limited descriptions.
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: querying BigQuery to return the full multi-touch attribution path for a specific account domain. It specifies the verb 'query', the resource 'attribution path', and the scope 'for a specific company account domain'. This distinguishes it from sibling tools that handle summaries or different metrics.
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 explicitly notes that the tool is essential for B2B account-based attribution and surfaces cross-platform journeys missed by platform-level reports. It also warns that BigQuery mode must be enabled (BIGQUERY_PROJECT_ID env var). However, it does not explicitly state when not to use or suggest alternatives.
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 present, so the description bears full responsibility for behavioral disclosure. It describes only the content of the response, not whether the operation is read-only, safe, or requires special permissions. For a retrieval tool, this is minimal and leaves uncertainty.
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?
A single sentence that is direct, front-loaded with the action, and lists key outputs without redundancy. Every word adds value.
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 no parameters, no output schema, and no annotations, the description provides a reasonable overview of the tool's output. However, it could mention that the tool is read-only or safe to call, and note if the response is structured (e.g., JSON).
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?
There are no parameters, so the baseline is 4. The description adds meaningful context about what the tool returns, compensating for the empty 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 retrieves the asset library overview, listing specific components (DAM system name/URL, access instructions, brand/copy guidelines, asset categories). It is distinct from sibling tools like list_asset_categories or get_asset_specs.
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?
No explicit guidance on when to use this tool versus alternatives. Usage is implied (for a high-level overview), but no exclusions or sibling comparisons are provided.
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 must disclose behavioral traits. It does not mention that the tool is read-only, has no side effects, or any performance/permission considerations. As a simple overview tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. No unnecessary words.
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?
For a tool with no parameters and low complexity, the description suffices by listing the key summary items it returns. However, without an output schema, the agent might benefit from knowing the exact structure (e.g., data types) but the description covers the main points.
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 no parameters (schema is empty). With 0 parameters, baseline is 4. The description compensates by explaining the output context, which is more than what the schema provides.
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: 'Get a high-level overview of the full audience library' and lists specific aggregated data points (count of first-party audiences, contracted data providers, etc.). This distinguishes it from sibling tools that drill into specific aspects.
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 for a broad overview but does not explicitly state when to choose this tool over siblings like `list_first_party_audiences` or `get_lookalike_strategy`. No when-not-to-use guidance is provided.
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 provided, so description carries full burden. Covers data source, row structure, row limit, truncation notice, and required environment variables. Does not detail output schema (none provided) or behavior when no filters applied, but sufficiently discloses key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the core purpose and gradually add detail. No filler; every sentence provides value.
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 4 optional string params and no output schema, the description covers data source, content, return structure, filtering, row cap, truncation, and environment variables. Could mention behavior with no filters, but overall complete for effective 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 has 0% description coverage, but description compensates by explaining that start_date, end_date, platform, and campaign_id are for filtering. However, it does not specify date formats, valid platform values, or that parameters are optional, limiting practical parameter usage guidance.
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 it queries daily campaign metrics (spend, impressions, clicks, conversions) from a unified BigQuery view across multiple platforms. It distinguishes itself from sibling tools like 'get_campaign_performance' by specifying the cross-channel, aggregated nature, though it doesn't explicitly differentiate from all 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct guidance on filtering by date range, platform, or campaign_id to narrow results. Mentions the 150-row cap and advises applying tighter filters if truncation occurs. Lacks explicit when-not-to-use guidance but is adequate for typical 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?
With no annotations, the description carries full burden. It discloses the BigQuery requirement and classification thresholds (90 days), which is helpful. However, it does not mention side effects, performance impact, or whether it is read-only, leaving gaps for an agent.
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 concise at two sentences, front-loaded with the core classification purpose, and every sentence adds value. No wasted words.
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 no annotations or output schema, the description covers purpose and use case adequately but lacks parameter details and behavioral transparency. For a tool with 3 parameters and no schema descriptions, more detail on input usage and output expectations would improve completeness.
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 coverage is 0%, yet the description does not explain the three parameters (account_tier, crm_pipeline_stage, web_presence_status). For instance, it mentions 'target accounts' but doesn't link to account_tier, and the input web_presence_status seems to conflict with the classification output. No guidance on format or enum meanings is provided.
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 classifies target accounts by web presence into three specific categories (dark, lapsed, visible), using specific verbs like 'classify' and 'identify'. It distinguishes from sibling tools by focusing on web presence classification rather than general account or funnel metrics.
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 use cases: identifying invisible accounts in pipeline stages and triggering outreach. It gives context ('in key pipeline stages', 'requires BigQuery mode') but does not explicitly state when not to use or list alternatives, though no direct sibling offers this classification.
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 should fully disclose behavioral traits. It only lists return content, leaving out whether the operation is read-only, idempotent, requires authentication, or has side effects. The verb 'Get' implies reading, but this is not explicit.
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 no superfluous words. It immediately states the purpose and lists key components, achieving maximum conciseness while remaining informative.
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 no parameters and no output schema, the description provides a reasonable overview of what is returned. However, it lacks structural details (e.g., format, nesting) and does not clarify the scope (e.g., which account or platform context applies). This leaves minor gaps for an agent to infer.
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 zero parameters, so the description correctly focuses on the output. It adds meaning by enumerating the returned data elements (seed audiences, expansion percentages, best sizes, notes), which is not present in the schema. This is effective for a parameter-less tool.
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 retrieves the full lookalike audience strategy, listing specific components like seed audiences, expansion percentages, best sizes, and strategic notes. It uses a specific verb+resource and distinguishes itself from sibling tools, none of which cover lookalike strategy.
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 does not explicitly state when to use this tool versus alternatives. While it implies it's the go-to for lookalike strategy, there is no guidance on prerequisites, exclusions, or situational use cases, leaving room for ambiguity.
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 disclosure. It describes the operation as retrieving a structure, which implies a safe read operation, but does not mention permissions, rate limits, or any potential side effects. It is minimally transparent but not misleading.
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, clear sentence that is front-loaded with the key information (verb and resource) and provides enough detail without any waste. It earns its place.
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 simple single-parameter input and no output schema, the description is fairly complete. It explains what the tool returns (full structure including sections, metrics, etc.), which is sufficient for an agent to understand its purpose. Minor gaps: no mention of possible errors or return format, but adequate for a straightforward get operation.
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 has 100% coverage with a single parameter 'template_id' described as 'The reporting template ID'. The description adds context that the tool returns the full structure, which indirectly confirms the parameter's purpose, but does not add meaning beyond the schema. Baseline score 3 is appropriate.
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 verb 'Get' and the resource 'reporting template', and specifies what is included: sections, metrics, dimensions, and visualizations. This distinguishes it from the sibling 'list_reporting_templates' which lists templates rather than retrieving one full structure.
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 that this tool is used when you need the detailed structure of a specific template, but it does not provide explicit guidance on when to use it versus alternatives like 'build_performance_report' or when not to use it. There are no exclusions or alternative suggestions.
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 burden. It states what is returned (objectives, KPIs, etc.) but omits behavioral traits like read-only nature, auth requirements, or rate limits. Adequate but not detailed.
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?
Single sentence that is front-loaded with the action and lists key elements. No superfluous words.
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?
For a simple retrieval tool with one parameter and no output schema, the description provides sufficient context about what is returned. Could mention response format or error handling but still adequate.
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 has 100% coverage for team_id. Description does not add extra meaning beyond schema. Baseline score of 3 applies as schema already documents the parameter.
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?
Description clearly states it retrieves full details for a single media team, listing specific components (objectives, KPIs, platforms, etc.). This distinguishes it from siblings like list_teams and get_team_for_account.
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?
Description implies when to use (when you need full details of one team) but does not explicitly guide when not to use it or compare with siblings like list_teams or get_team_for_account. Minimal usage context provided.
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 must disclose behavioral traits. It only states the basic operation (get aggregated data) but omits details like whether it's read-only, auth requirements, or rate limits. The 'Get' prefix suggests a non-destructive operation, but no explicit confirmation.
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 sentence with no unnecessary words. Every part is essential: the verb, resource, scope (across all campaigns for a team), and optional date range. Highly efficient.
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?
The tool retrieves performance data but has no output schema. The description does not explain what metrics are returned, how the data is structured, or any aggregation details. This leaves the agent guessing about the return format.
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 only 33% (team_id has description). The description adds context for date_from and date_to by saying 'within an optional date range', which compensates for the lack of schema descriptions for those parameters.
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 uses a specific verb 'Get' and clearly identifies the resource as 'aggregated performance data across all campaigns for a team', distinguishing it from sibling tools like 'get_campaign_performance' which is per campaign.
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 this tool is for team-level performance data across campaigns, and optional date range is mentioned. However, it doesn't explicitly state when to use this versus alternatives like 'get_campaign_performance' or provide exclusions.
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, the description carries the burden. It states the tool returns active alerts of specific types and implies the impact on attribution reliability. However, it lacks details on output structure, pagination, or edge cases, making it adequate but not comprehensive.
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 concise with two sentences. The first sentence states purpose, and the second provides usage guidance. No unnecessary information.
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 no annotations or output schema, the description provides good usage context but lacks parameter explanation and return value details. It is fairly complete for a simple tool but could be improved.
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%, and the description does not explicitly explain the 'status' parameter. It mentions 'active alerts' but doesn't define the status enum or how filtering works, leaving a significant gap.
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 'Get data quality alerts from the Watchdog agent' and lists specific alert types (signal capture rate drops, null CRM fields, etc.). It distinguishes from sibling tools by focusing solely on watchdog alerts.
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 explicitly advises to check this tool before running attribution analysis, providing clear context for when to use it. However, it doesn't mention when not to use it or compare to alternatives, though no direct sibling exists.
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 provided, so description carries full burden. It mentions returned elements but lacks details on pagination, limits, ordering, or side effects. Adequate but not thorough.
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?
Single sentence, front-loaded with main action, no filler. Efficient and well-structured.
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?
Description covers purpose and return content without output schema. Lacks pagination/limits but acceptable for a small list of categories. Mostly complete.
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?
With 0% schema description coverage, the description only adds 'Optionally filter by asset type', which is minimal. The enum values are not explained further. Baseline 3 is appropriate.
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?
Description clearly states 'List asset categories' with specific details (storage locations, naming conventions, platform specs), distinguishing it from sibling get_asset_category.
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?
Provides optional filtering but no explicit guidance on when to use list vs get_asset_category or other siblings. Usage is implied but not explicitly scoped.
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 provided, so description bears full burden. Description accurately portrays a read-only list operation but does not disclose rate limits, side effects, or any behavioral details beyond the output summary.
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?
Single sentence, under 200 characters, front-loaded with purpose. No unnecessary words.
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?
For a zero-parameter, no-output-schema tool, description explains what is returned (list of platforms with format, entity types, upload process). Could be slightly more detailed about output structure, but adequate.
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?
No parameters, schema coverage 100%, baseline 4. Description adds no parameter info, which is acceptable since there are none.
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?
Description clearly states the tool lists GMP platforms supporting bulk upload, specifies examples (DV360 SDF, etc.) and what the summary includes (format, entity types, upload process). It is a specific verb+resource, and no sibling tool has the same purpose.
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 on when to use this tool versus alternatives (e.g., get_bulk_upload_schema or get_bulk_upload_instructions). The description does not mention any exclusions or 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?
No annotations provided; description lacks disclosure of any behavioral traits like pagination, sorting, read-only nature, or data freshness. For a simple list, minimal behavior is expected, but still no mention.
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?
Single sentence, front-loaded, no wasted words. Efficiently communicates purpose.
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?
No output schema; description is adequate for a simple list tool with no parameters. However, it misses potential details like order or pagination, but given simplicity, it's nearly 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?
Input schema has zero parameters, so description carries no parameter burden. As baseline for 0 params is 4, the description adds value by specifying the content of the list (objectives, KPIs, etc.) beyond 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?
Description clearly states the tool lists all media teams with specific attributes (objectives, KPIs, managed platforms, account assignments). It distinguishes from sibling tools like get_team (singular) and list_team_members (specific to members).
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?
No explicit guidance on when to use vs alternatives (e.g., get_team for a single team). Context suggests it's the broad listing tool, but no when-not-to or alternatives mentioned.
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, the transparent description of listing and filtering suffices for a simple read operation. However, it does not disclose potential behavior like pagination, sorting, or performance considerations. The description does not contradict any 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: two sentences with no wasted words. The key verb and resource are front-loaded, and the rest is efficiently structured.
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?
For a simple list tool with optional filters and no output schema, the description covers the essential functionality. It provides enough context for an agent to use it, though it could mention return format or edge cases like empty results.
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 coverage is 0%, but the description lists the filterable dimensions (status, type, team, or platform), adding context beyond the schema's enum lists. It does not explain enum values or parameter relationships, providing only marginal added meaning.
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 it lists tests, covering both in-campaign A/B tests and vendor/partner evaluations, which distinguishes it from siblings like 'get_test' that likely fetch individual tests. The verb 'List' and resource 'tests' are specific and unambiguous.
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 by listing what it covers, but does not explicitly state when to use this tool versus alternatives like 'get_test' for single test details. No exclusions or alternatives are mentioned, leaving room for ambiguity.
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?
Given no annotations, the description discloses the data source (BigQuery view), aggregation behavior (all-time metrics, capped at 150 rows), filtering by start/end date, and required credentials. It implies read-only operation but does not explicitly state non-destructive nature. Overall, behavior is well-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 well-structured with bulleted layers, front-loads the core purpose, and each sentence adds value (data source, metrics, filtering, row cap, prerequisites). No extraneous 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?
Despite no output schema or annotations, the description covers the data source, layers, filtering, row cap, and prerequisites. Minor gap: missing parameter details for platform and campaign_id, but overall complete for a read-only query tool.
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 coverage is 0%, and the description only explains the start_date/end_date filtering purpose. It does not elaborate on platform or campaign_id parameters, leaving their semantics ambiguous. The description should have described all four parameters to compensate for the schema gap.
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 compares campaign performance across three measurement layers (Platform, Traffic, Revenue) using a specific BigQuery view. It lists metrics and layers, and the mention of MTA attribution comparison distinguishes it from sibling tools like get_campaign_performance or get_attribution_results.
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 explains when to use (comparing performance across layers) and mentions prerequisites (required project and dataset). However, it does not provide when-not-to-use guidance or explicitly name alternative sibling tools, leaving the agent to infer context 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?
No annotations are provided, so the description carries full burden. It states the tool returns a coverage map with priorities, implying it is read-only and computes gaps. However, it does not disclose permissions needed, data freshness, or any side effects. The behavior is described adequately but not comprehensively.
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 concise with two sentences and an example, all front-loaded. The first sentence states the core purpose, the second describes the return value. Every sentence adds value with no unnecessary words.
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?
The tool has moderate complexity (coverage analysis across platforms) and no output schema. The description provides a high-level output description ('coverage map with implementation priority') but does not detail the output structure or schema. For a tool with no output schema, more completeness about the return format would be beneficial.
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 has 0% description coverage for the single parameter 'platforms'. The description adds meaning by stating 'a given set of platforms' and providing an example ('Meta and LinkedIn'), indicating it expects platform names. However, it does not specify the parameter type (array, string) or allowed values, leaving ambiguity.
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 uses the specific verb 'review' and resource 'identity signal namespaces' for given platforms. It provides a concrete example ('Meta and LinkedIn') and clarifies the output is a coverage map with implementation priority, distinguishing it from sibling tools like list_identity_namespaces or get_identity_namespace.
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 explains the tool's purpose ('identify gaps in coverage') with a clear example. However, it does not explicitly differentiate from similar sibling tools (e.g., check_signal_capture_health) or state when not to use it (e.g., for querying a single namespace). The guidance is clear but lacks explicit 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 must disclose behavioral traits. It describes the output but does not state that the operation is read-only, non-destructive, or require specific permissions. For a data retrieval tool, this is a notable gap as the agent cannot infer safety from the description alone.
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 sentence that efficiently communicates the tool's purpose and output. It lists key fields without excessive detail. While it could be structured into bullet points for clarity, the conciseness is appropriate for a straightforward retrieval tool.
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 (one parameter, no output schema), the description adequately covers the output by listing relevant fields. It does not include edge cases or error conditions, but for a basic 'get by ID' tool, the completeness is sufficient.
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 coverage is 100% with a single parameter 'test_id' described as 'Test ID'. The description adds meaning by enumerating the output fields (hypothesis, variants, results, etc.), helping the agent understand what constitutes 'full details' and how to interpret the response. This exceeds the baseline of 3.
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 uses a specific verb 'Get' and explicitly names the resource 'full details for a single test', listing the fields included (hypothesis, variants, results, etc.). This clearly distinguishes it from sibling tools like list_tests which returns a list, or get_test_learnings which may have a different scope.
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 that this tool is for retrieving comprehensive details for one test, contrasting with list_tests for listing. However, it does not explicitly state when not to use it or mention alternatives like get_test_learnings. The context signals and sibling list make the intended use clear, but exclusions are missing.
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, the description carries full burden. It mentions return fields (budget, targeting, status) but does not disclose pagination, limits, or authentication. It adds some value but leaves gaps for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no unnecessary words. Efficient and structured well.
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 no output schema, the description partially compensates by mentioning returned fields but lacks details on pagination, sorting, or full response structure. It is adequate but not fully complete.
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 coverage is 0%, and the description adds meaning by explaining that parameters are filters. However, it omits account_id, and does not detail parameter usage beyond the enum values already in 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 'List and filter paid media campaigns,' specifying the verb and resource. It lists the filter dimensions, aligning with the parameters, and distinguishes from siblings like get_campaign for single campaigns.
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 for listing multiple campaigns through the verb 'list', but does not explicitly state when not to use it or contrast with siblings like get_campaign. It lacks exclusion guidance but is still clear enough for an agent to infer.
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, the description carries the full burden. It mentions the return fields (template structure, metrics, delivery format, cadence) but lacks details on pagination, limits, or permissions. It does not contradict annotations (none provided).
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 two sentences with no redundant words. It front-loads the main action and then provides filtering and return details efficiently.
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 no output schema, the description partially covers return values. However, it omits default behavior when no filter is applied, ordering, size limits, and required permissions. The tool is a list operation, so completeness is moderate.
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%, but the description adds context by explaining the 'audience' parameter as a filter and listing the allowed values. This goes beyond the raw schema which only has the enum definition.
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 verb 'List' and the resource 'available reporting and dashboard templates', and distinguishes from sibling tools like get_reporting_template (single template) and build_performance_report (creation). It also mentions filtering by audience, giving specific enum values.
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 for listing templates with optional audience filtering but does not explicitly state when to use this tool over alternatives like get_reporting_template or build_performance_report. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results come from the most recent Analyst agent run and are distinct from platform-reported attribution, but does not mention prerequisites (e.g., agent run must exist), data freshness, or potential errors. Adequate but not comprehensive.
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?
Two sentences: first states core function and results, second adds context and parameter usage. No redundant words, front-loaded with purpose.
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 no output schema, description adequately details returned fields (attributed conversions, value, spend, CPA, ROAS, credit share). Mentions distinction from platform-reported attribution. Lacks mention of error cases if no run exists, but otherwise complete for a simple tool.
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 coverage is 0%, so description must compensate. It explains the parameter 'conversion_type' as a filter for B2B pipeline stages or B2C events, providing examples (e.g., 'opportunity_created'). This adds significant meaning beyond the schema's empty string type.
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?
Description clearly states the verb 'Get', the resource 'multi-touch attribution results from the most recent Analyst agent run', and details the returned metrics (weighted credit by channel/platform). This distinguishes it from siblings like get_attribution_run_history or compare_attribution_models.
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 for retrieving the latest MTA results and mentions filtering by conversion_type, but does not explicitly contrast with sibling tools like get_attribution_run_history for historical data or compare_attribution_models for model comparison. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the read-only nature ('Look up'), lists the returned data fields, and explains the data source ('Populated by the Analyst agent's IP intelligence enrichment pipeline'). It adds context beyond the schema, though it lacks details on rate limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, return fields, data source, and requirement. No wasted words.
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?
The description covers the return fields, data source, and usage requirement. With no output schema, the listing of returned fields is helpful. However, it omits details about pagination, errors, or timeout behavior, which are minor given the simplicity of a single-parameter lookup.
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 already provides a clear description for company_domain (100% coverage). The tool description adds no additional parameter semantics beyond restating the resource type, so a baseline score of 3 is appropriate.
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 verb ('look up') and resource ('enriched firmographic profile for a company domain'), and lists the specific fields returned. It distinguishes this tool from siblings by focusing solely on firmographic data from the enrichment pipeline.
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 mentions a prerequisite ('Requires BigQuery mode'), which provides some usage guidance. However, it does not specify when to use this tool versus alternatives (e.g., get_account or get_company_sessions) nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation ('Get full details') and lists returned fields, but does not mention safety, idempotency, auth requirements, or rate limits. For a simple fetch tool, it is moderately transparent but lacks explicit behavioral cues.
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?
Two sentences: the first is dense with key information, the second provides use cases. No wasted words or repetition. The description is efficiently structured 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 a single parameter and no output schema, the description adequately explains what is returned and when to use it. It does not mention output format or pagination, but for a detail-fetch tool, the information is sufficient for an agent to understand its purpose and usage.
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 100%, and the parameter namespace_id is already well-documented in the schema with examples. The tool description does not add additional parameter semantics beyond listing what the response includes, which is unrelated to the parameter meaning.
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 verb 'Get full details' and resource 'identity signal namespace', and lists specific aspects returned (capture method, lifetime, PII status, platforms, implementation notes). This distinguishes it from siblings like list_identity_namespaces (list all) and get_identity_signal_coverage (coverage).
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 use cases: 'Useful when setting up a new signal or diagnosing a stitching gap.' It does not explicitly state when not to use or mention alternatives, but the context is clear enough for appropriate tool selection.
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 full burden. It lists output content but does not disclose behavioral traits like data freshness, permission requirements, or side effects. For a read-only tool, this is adequate but not exemplary.
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?
Single sentence, front-loaded with the key purpose, and no wasted words. Efficient and clear.
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?
The description lists specific return elements, compensating for lack of output schema. However, with sibling tools covering similar areas, a note on scope or limitations would improve completeness.
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?
There are no parameters; the schema coverage is 100% (empty). Per rubric, 0 parameters baseline is 4. The description adds no parameter meaning because none exist, which is fine.
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 it provides a high-level overview of measurement setup, listing specific components like tag management, implementation type, pixel count, etc. This distinguishes it from sibling tools like get_tag_management or list_measurement_partners.
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 for getting a quick summary, but provides no explicit guidance on when to use this versus alternatives. With many sibling tools, explicit exclusions or recommendations would help.
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 states 'Get details,' indicating a read operation with no side effects. However, it does not disclose any authorization requirements, data freshness, or whether the results are comprehensive or filtered. The description is adequate but lacks depth.
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, well-structured sentence that immediately states the purpose and provides examples. Every word adds value, with no redundancy or filler.
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?
For a simple tool with no parameters and no output schema, the description is complete. It clearly explains what the tool returns. A score of 5 would require additional context like typical use cases or data sources, but 4 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?
The tool has zero parameters and the schema is empty (100% coverage). Per guidelines, baseline for zero parameters is 4. The description adds value by specifying what details are returned, which is sufficient given no parameters to document.
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 uses a specific verb ('Get details') and resource ('first-party data onboarding platforms and clean rooms'), provides examples (LiveRamp, Habu, InfoSum), and lists the details returned (platforms, use cases, contact info). This clearly distinguishes it from sibling tools like get_tag_management or measurement partners.
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 for retrieving onboarding platform info but provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions. Given the simple nature of a zero-param tool, this is acceptable but minimal.
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?
No annotations provided; description discloses the scoring formula, behavior of intent_spiking, and required mode. Does not mention side effects or read-only nature, but sufficiently transparent for a read-like operation.
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?
Three sentences front-loaded with purpose, then scoring formula, then a usage tip. No wasted words, efficiently 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?
No output schema or annotations; description provides scoring algorithm and a requirement but lacks details on response format and parameter semantics, making it minimally adequate.
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, the description only explains intent_spiking; other parameters (limit, account_tier, min_sessions_30d, etc.) are not described, leaving agents to infer meaning from names and enums alone.
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 returns ranked target accounts from the dark funnel sorted by a composite priority score, distinguishing it from sibling tools like get_target_account_activity.
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?
Provides explicit prerequisites (BigQuery mode, completed enrichment run) and a tip on using intent_spiking. Lacks explicit when-not-to-use or alternatives, but overall guides appropriate 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 must carry the behavioral burden. It accurately describes the action as a read operation ('Get') without mentioning side effects, permissions, or potential errors. While adequate, it adds no extra transparency beyond the obvious.
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?
A single, efficiently structured sentence that front-loads the purpose and lists specific data points with no extraneous words.
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?
Without an output schema, the description covers the returned data components well but could improve by indicating the structure or format of the response. It is mostly complete for a simple read tool.
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?
There are zero parameters, and schema coverage is 100% (vacuously). The baseline score for 0 parameters is 4, and the description does not add parameter information since none exist.
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 specifies that the tool retrieves the website data capture setup, listing exact components (data layer, analytics platform, first-party cookie config). It effectively distinguishes this from related sibling tools like 'get_tag_management' or 'get_cm360_setup'.
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 data capture setup details but does not provide explicit guidelines on when to use this tool versus alternatives or when not to use it. Context is clear but lacks exclusions.
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 burden. It discloses that results include CPM premium estimates and performance notes, adding value beyond a simple list. However, it does not mention safety (e.g., read-only nature) or authorization needs.
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?
Two concise sentences with no extraneous information. The first sentence states the core function, and the second clarifies filters and additional content. It is front-loaded and efficient.
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 lack of output schema and annotations, the description adequately covers what the tool returns: a list of segments/layers with CPM estimates and performance notes. It is sufficiently complete for an agent to understand the tool's purpose and output.
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 schema has 0% description coverage on its 3 optional parameters. The description explicitly maps each parameter purpose: 'Filter by platform, default use, or best-performing flag' directly corresponds to platform, defaults_only, and best_performers_only, respectively. This significantly adds meaning beyond the bare 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 it lists third-party audience segments and layers used as targeting overlays, with optional filters. This verb+resource combination is specific and distinguishes it from related tools like list_first_party_audiences.
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 mentions filtering by platform, defaults, or best-performing, which gives usage hints. However, it does not provide explicit guidance on when to choose this tool over alternatives or 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.
Behavior4/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 the prerequisite (BigQuery mode) and excludes negative keywords. It lists returned metrics but does not mention whether the operation is read-only, permissions required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: first defines the tool's core output, second details actionable filters. No redundant information; every sentence adds value.
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?
With no output schema or annotations, the description covers return metrics and two filter parameters. However, it omits explanations for three parameters (platform, min_spend, campaign_id) and does not describe output structure, pagination, or data limits, leaving gaps for a tool with this complexity.
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 coverage is 0%, and the description explains two of five parameters (low_quality_score and lost_is_budget) with purpose and usage examples. The remaining three parameters (platform, min_spend, campaign_id) are left unexplained, requiring the agent to infer their meaning from names.
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 explicitly states the tool returns 'keyword performance with spend, quality scores, and Google impression share metrics', specifying the metrics and excluding negative keywords. It clearly distinguishes from sibling tools like get_campaign_performance or get_ad_performance by focusing on keyword-level data.
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 guidance for optional filters: low_quality_score for SQO opportunities and lost_is_budget for budget-throttled keywords. However, it does not mention when not to use this tool or suggest alternatives for broader filtering.
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?
No annotations are provided, so the description carries the full burden. It discloses that the action is logged to operator_action_log, and describes the two execution paths (forwarding to agent route with guardrail vs. queuing for manual approval). This provides good insight into behavioral traits beyond a simple mutation.
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 at 4-5 sentences, front-loaded with the primary action. It includes relevant details about logging and approval flows without being overly verbose. Slightly more could be trimmed, but it's well-structured.
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 no output schema and 5 required parameters, the description covers purpose, behavior, and conditional execution. It does not describe return values or post-action confirmation, but for an action tool with clear context, this is adequate.
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 60%, and the description does not add significant meaning beyond the schema. The 'domains' parameter lacks description in both schema and description text. The description reiterates the platform enum and mentions rationale's purpose in the approval queue, but overall adds marginal value.
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 verb 'Add' and the resource 'audience exclusion list', specifying the goal to stop top-of-funnel ads for pipeline accounts. It distinguishes from sibling tools which are primarily read-oriented, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to suppress ads for accounts in open pipeline. It lists supported platforms and calls it a 'closed-loop action'. However, it does not explicitly state when not to use or provide alternatives to other similar tools, though the context is still clear.
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 must bear the full burden. It describes what the tool returns but omits side effects, permissions, rate limits, or error conditions. The tool is likely a read operation, but this is implied rather than stated.
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 two sentences, extremely concise, and front-loaded with the core purpose. Every word adds value; no fluff or repetition.
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 2 parameters, no output schema, and no annotations, the description covers the purpose, input hints, and output content (column names, types, etc.). It could be more explicit about the output shape, but it is sufficient for a schema retrieval tool.
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 coverage is 50% (platform is documented with enum, entity_type has a string description without enum but with per-platform options in the description). The description adds value by listing entity_type options per platform and clarifying that returns include defaults. This supplements the schema adequately.
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 it gets the full field schema for a platform bulk upload entity type, with examples (DV360 line_item, SA360 campaign). It specifies what is returned (column names, data types, required status, valid values, defaults). There is no sibling tool with similar purpose, making it unambiguous.
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 when to use (when needing the schema for a bulk upload entity type) but does not explicitly exclude scenarios or mention alternatives. Given sibling tools, no other tool provides schemas, so it is clear but lacks explicit guidance on prerequisites or context.
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 provided, so description carries full burden. It describes the report contents and column interpretation but lacks details on read-only nature, data freshness, or auth requirements. Adequate but not thorough.
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?
Three concise sentences: report content, column explanation, and use case/requirement. No fluff, front-loaded with key info.
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?
No output schema, but description details output columns (CPA, ROAS, etc.) and the gap metric. Also mentions BigQuery requirement. Sufficient for using the tool, though could add permission or data scope details.
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?
No parameters (input schema empty), so schema description coverage is 100% by default. Baseline 4 applies. Description adds no parameter info but none needed.
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?
Description clearly states it's a cross-channel efficiency report with specific metrics (CPA, ROAS, pipeline share, spend share) and the gap column. Distinguishes from sibling tools by focusing on cross-channel efficiency rather than campaign or benchmark reports.
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?
Explicitly states use case 'Use for budget allocation recommendations' and prerequisite 'Requires BigQuery mode.' While it doesn't list alternatives or when not to use, the guidance is clear and actionable.
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 must cover behavioral traits. It describes what is returned (account ID, Floodlight config, u-variables) but does not mention authentication, error cases, or side effects. Since it is a read-only retrieval, the transparency is adequate but not fully comprehensive.
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, information-dense sentence. Every word contributes meaning, listing exactly what is returned. There is no redundancy or unnecessary detail.
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 zero parameters and no output schema, the description adequately covers the tool's purpose and output. However, it could be improved by noting that the operation is read-only or indicating potential errors (e.g., if not configured). Overall, it is sufficient for a simple retrieval tool.
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?
There are zero parameters and schema coverage is 100% (vacuous). The description adds no parameter info, which is acceptable because there are no parameters to explain. A baseline of 4 is appropriate.
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 that the tool retrieves Campaign Manager 360 configuration, listing specific items like account ID, Floodlight configuration ID, and u-variables with detailed attributes. This distinctively differentiates it from siblings such as get_account or get_tag_management.
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 implicitly conveys usage context: use this to retrieve the complete CM360 setup. While it does not explicitly state when not to use it or list alternatives, the purpose is obvious enough that an agent can infer appropriate usage.
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, the description bears full responsibility. It discloses the return values including the intent score formula, specific fields like pricing_page_sessions, and the intent_spiking flag. It also states the BigQuery requirement, which is a behavioral constraint. No mention of rate limits or permissions, but adequate for a read-like operation.
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 concise at three sentences, front-loading the main purpose and key output. Every sentence adds value: purpose, formula details, specific return fields, use case, and a prerequisite. No wasted words.
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 medium complexity (composite score, multiple return fields) and no output schema, the description provides good detail about what is returned. It covers the main outputs but does not mention pagination or limits, which are likely irrelevant for a single-company summary. Overall, it is sufficiently complete.
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 covers 50% of parameters with descriptions (company_domain has a description). The description adds no extra meaning for either parameter beyond what the schema provides. For period_type, the description implies rolling periods but does not elaborate on values. This is adequate but fails to fully compensate for the lower 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 returns a rolling engagement summary with a composite intent score, specifying the verb 'return' and resource 'engagement summary for a company'. It differentiates from siblings like get_company_profile by highlighting the unique intent score and specific output fields.
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 explicitly says 'Use this for a quick account health check before outreach,' providing clear context for when to use it. It also mentions 'Requires BigQuery mode' as a prerequisite. However, it does not mention when not to use the tool or list alternatives, so it's slightly lacking.
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 implies a read-only action by describing retrieval, and warns that approvals expire. However, it does not explicitly state whether the tool modifies state or other safety aspects.
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?
Two sentences, well-structured with the purpose first. No extraneous words; every sentence adds value.
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 no output schema or annotations, the description is fairly complete. It explains what is returned and a time constraint. Missing details like ordering or state effects, but acceptable for a zero-parameter retrieval tool.
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 parameters, so schema coverage is 100%. The description adds meaning by explaining the content of each approval (action, affected entity, rationale, impact, budget), which compensates for the lack of parameters.
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 gets 'media actions proposed by the Operator agent that are awaiting human approval' and details what each approval includes (action, affected entity, rationale, impact, budget). This distinguishes it from sibling tools like 'get_tag_management' or 'list_teams'.
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 mentions to review approvals before they expire and that the Operator agent will not execute until approved, implying when to use. However, it does not explicitly specify when not to use this tool or provide alternatives.
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?
No annotations are provided, so the description carries the full burden. It clearly describes a read-only listing operation with no destructive behavior. It provides examples of returned content, but doesn't mention pagination, rate limits, or access requirements, which are minor 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 two sentences with no wasted words. It front-loads the main purpose and uses examples efficiently to convey scope.
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 sibling tools and lack of output schema, the description provides sufficient context for a listing operation. It explains the types of signals covered and filtering, but could be more specific about output format or limits.
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 explains the category parameter well by listing examples and noting filtering. However, the platform parameter is not mentioned at all, leaving its purpose unclear.
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 lists all registered identity signal types from a shared schema registry, with specific examples. It distinguishes itself from siblings like get_identity_namespace by being a list operation, and from get_identity_signal_coverage by focusing on available types.
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 explicitly says 'Use this to understand what signals are available for identity stitching,' giving clear context. It also advises filtering by category for a focused list. However, it does not explicitly mention when to use alternatives like get_identity_namespace or the platform 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?
Although no annotations are provided, the description implies a read-only operation by stating it 'reads from' logs and alerts. It does not explicitly declare safety or permissions, but the detail on data sources and lack of side-effect language is fairly transparent.
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 concise, with the main action and context in the first sentence, and additional guidance in subsequent sentences. No unnecessary words.
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 no output schema and two undocumented parameters, the description covers the tool's purpose, use cases, and differentiation from a sibling. It lacks parameter details but otherwise provides sufficient context for a monitoring tool.
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 two parameters (platform, hours_back) with 0% description coverage in the schema. The description does not explain what these parameters do or how they affect results, leaving a significant gap for the agent.
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 checks capture rates for identity signal namespaces against thresholds, naming specific data sources (watchdog_capture_rate_log, watchdog_alerts) and distinguishing itself from the sibling get_watchdog_alerts by mentioning trend direction.
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 use cases: diagnosing tracking problems, before attribution analysis, or when data quality is questioned. It also contrasts with get_watchdog_alerts to guide tool selection.
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 states that the agent runs asynchronously, which is a key behavioral trait, and that results are available after a few minutes via other tools. However, it does not disclose potential failure modes, rate limits, or side effects of triggering multiple runs. For a tool with no annotations, this is adequate but could be improved.
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 three concise sentences: first introduces the action and agent types, second states the configuration prerequisite, third explains async behavior and result retrieval. There is no redundant information or wordiness; every sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple trigger tool with 2 parameters, no output schema, and moderate complexity, the description covers all key aspects: what the tool does, which agents it triggers, the environment requirement, the async nature, and how to obtain results. It provides sufficient context for an AI agent to use the tool correctly and know what to expect.
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 2 parameters and 50% schema description coverage, the description adds significant value: it explains the meaning of each agent enum value ('watchdog' for data quality audit, etc.) and the reason parameter purpose ('brief explanation of why this run is being triggered manually'). The schema only documents the reason parameter, so the description compensates well by providing context for both parameters.
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: 'Trigger an on-demand run of one of the autonomous agents'. It lists the three specific agents (watchdog, analyst, operator) with their responsibilities, distinguishing this trigger tool from sibling tools like get_attribution_run_history or get_watchdog_alerts that are purely retrieval tools.
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 specifies when to use the tool (on-demand run) and provides context: the agent runs asynchronously, requiring follow-up with get_attribution_run_history or get_watchdog_alerts to check results. It also mentions the environment variable prerequisite (PAID_MEDIA_AGENT_URL). While it doesn't explicitly list when NOT to use it or alternative direct tools, the guidance is clear enough for an agent to understand the context.
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?
Since no annotations exist, the description carries the full burden. It discloses that it reads recent CRM leads, returns statistics, and explains the implication of results. No side effects or destructive behavior are mentioned, which is appropriate.
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 concise and well-structured. Each sentence adds value: action, output details, implication, and cross-reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter with no schema description, the description provides sufficient detail: fields checked, return metrics, time window, and downstream usage. It is contextually complete for this simple scan tool.
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 only parameter 'since_hours' has no schema description, so the description must compensate. It mentions 'leads created in the past N hours', implying the parameter controls the time window. This adds meaning but could be more explicit about the parameter name.
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 it scans CRM leads for missing media identifier fields, returning count and percentage. It distinguishes from sibling tools by mentioning cross-reference with check_signal_capture_health.
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 explains the tool is used to detect a broken tracking pipeline and suggests cross-referencing with check_signal_capture_health. It provides clear context but does not explicitly 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: forwarding to agent route, operator guardrails (MAX_BUDGET_SHIFT_PCT cap, OPERATOR_REQUIRE_APPROVAL), logging to operator_action_log, and queuing for manual execution if no agent URL. This is comprehensive and transparent.
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 three sentences long and front-loaded with the core purpose. While it could be slightly more concise, every sentence adds value and there is no redundant 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?
The description covers the main flow and guardrails but omits what the tool returns (no output schema). Given the complexity of budget reallocation with approval flows, the description is largely complete for an agent to understand when and how to invoke it, though a brief note on the response would improve it.
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 covers 67% of parameters with descriptions. The description adds context about the rationale parameter's importance ('Always provide the attribution insight') and the supported platforms (matching platform enum). It does not detail each parameter but enriches understanding of how they are used in the broader workflow.
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 'Shift budget from an underperforming campaign or line item to one with higher attributed pipeline contribution.' It uses a specific verb ('Shift') and resource ('budget'), and distinguishes itself from siblings as the only budget reallocation tool among many campaign and account retrieval tools.
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 detailed context on when to use this tool, including supported platforms and the behavior based on PAID_MEDIA_AGENT_URL configuration. It implies usage for performance-driven budget shifts but does not explicitly state when not to use it or provide alternatives, though no alternative exists among siblings.
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:

[![paid-media-mcp MCP server](https://glama.ai/mcp/servers/kenlim5656/paid-media-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kenlim5656/paid-media-mcp)

Score Badge

Copy to your README.md:

[![paid-media-mcp MCP server](https://glama.ai/mcp/servers/kenlim5656/paid-media-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kenlim5656/paid-media-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/kenlim5656/paid-media-mcp'

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