superwireless
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct resource/action, from presets to datasets to comparisons. Even the IoT-related tools (report, convert, design) have clear boundaries. Descriptions are detailed and effectively disambiguate similar-sounding tools like compare_scenarios, compare_arms, and compare_results.
Naming Consistency5/5All tools share the sw_ prefix and snake_case, with a consistent verb_noun pattern (e.g., list_presets, generate, validate, compare_arms). A few noun_phrases like mcs_info and sample_size are still readable and do not break the overall consistency.
Tool Count2/528 tools exceeds the 25+ threshold, making the surface heavy. While the domain is broad, many tools could be grouped (e.g., the interference trio), and agents may struggle to select the right one from such a large set.
Completeness5/5The full lifecycle is covered: planning (sw_plan, sw_revise), probing, generation, validation, evaluation, comparison, and reporting. External algorithm integration and preregistration complete the workflow. Minor features like dataset deletion are not necessary for the domain.
Average 4.2/5 across 28 of 28 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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.jsonto 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 carries the full burden of behavioral disclosure. It uses the verb 'view' which implies a read-only operation, but it does not explicitly state that it is non-destructive, nor does it disclose any prerequisites, error conditions, or side effects. This is a minimal level of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately conveys the tool's purpose and output, with no redundant words or filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the core functionality and the types of information returned. However, it lacks explicit usage guidelines and any note about read-only behavior, making it slightly less than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain the dataset_id parameter beyond the schema's 'Dataset Id' title. It merely alludes to 'generated datasets' in the tool description, which is a slight hint that the ID must refer to a generated dataset, but it provides no format, source, or validation details. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the active verb '查看' (view) and specifies the resource ('已生成数据集') and the specific outputs (dimensions, statistical distribution, available fields). This clearly distinguishes it from sibling tools like sw_list_datasets, which likely list datasets, and sw_validate, which validates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies a read-only inspection role but doesn't mention which scenarios call for it or exclude others. The context is clear from the tool name but no alternatives are referenced.
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 full behavioral disclosure. It only adds the qualifier 'generated locally', but does not disclose return format, error behavior, or whether the operation is read-only. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the essential purpose without wasted words. It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and the existence of an output schema (which presumably documents return values), the description is largely complete for a simple listing tool. It could potentially mention filtering or scope nuances, but the lack of such details is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics. It appropriately avoids redundancy by not referencing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出本机已生成的数据集' clearly states the verb (list) and resource (locally generated datasets). It also distinguishes this tool from siblings like sw_list_presets and sw_list_scenes by specifying the dataset scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools such as sw_list_results or sw_describe_dataset, leaving the context of use entirely implicit.
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 of behavioral disclosure. It discloses the optional filter behavior (if dataset_id is not given, list all), which is useful. However, it does not mention read-only nature, pagination, or any other side effects, making it only moderately 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and behavior. It contains no filler and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and an output schema, the description is fairly complete. It covers the primary behavior and the parameter's effect. The presence of an output schema reduces the need to explain return formats. Minor gap: no mention of sorting or limits, but not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (dataset_id) with no description, and schema description coverage is 0%. The description compensates by explaining that dataset_id is a filter and omitting it lists all results, adding meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists registered external algorithm results, using a specific verb ('列出') and resource ('外部算法结果'). This distinguishes it from sibling tools like sw_list_presets and sw_list_scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it explains that omitting dataset_id lists all results. However, it does not mention when to use this tool vs alternatives like sw_compare_results or any exclusions, leaving the agent without clear decision support.
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 the full burden. It explains that the tool performs three types of checks and returns a 'passed' flag, and instructs the user to fix configuration if 'passed' is false before proceeding. This is useful behavioral context, though it does not disclose side effects or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and organized into clear sections (check categories and usage recommendation). Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no annotations, and an output schema, the description covers the main purpose, usage timing, and key output ('passed'). It does not provide details on dataset_id or prerequisites, but the overall context is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, dataset_id, with no description (0% coverage). The tool description does not explain what dataset_id should contain, how to obtain it, or any format. The only hint is the reference to channel datasets, leaving the parameter semantics largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: validating the trustworthiness of a channel dataset for drawing conclusions. It lists three specific check categories (3GPP 38.901, physical laws, statistics) which adds detail, but it does not explicitly distinguish from sibling tools such as sw_gate or sw_calibrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'It is recommended to run once before Monte Carlo simulation.' This gives a clear context for when to use the tool. It does not mention alternatives or exclusions, but the recommendation is specific 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?
With no annotations, the description carries the full burden of disclosure. It effectively reveals that the tool returns executable code rather than data and that it does not rerun the simulation ('不必重跑仿真'). It also explains the default behavior (only channel if 'want' is omitted). However, it omits details about side effects, authorization requirements, or error handling, which would be valuable for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably compact, with three clear sections: core purpose, usage examples for 'want', and a note on reusability. It front-loads the key differentiator (returns Python, not data) and avoids any filler. Every sentence earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (2 parameters) and its focus on code generation, the description covers the essential aspects: what it returns, how to customize with 'want', defaults, and the critical fact that no simulation rerun is needed. There is an output schema, so return value details are not necessary. It could mention how to obtain a valid dataset_id (e.g., from sw_list_datasets), but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does this well for the 'want' parameter by providing natural language examples ('信道', '信道 + PMI + SRS RSRP', '我还想看时延功率谱') and clarifying the default (only channel). The 'dataset_id' parameter is not elaborated, but the description references it as an identifier for an existing dataset, which gives partial context. This is strong compensation for a 2-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates runnable Python code on demand, explicitly contrasting with returning data ('不是数据'). It specifies the scope (from a dataset) and the main verb (generate), which distinguishes it from sibling tools that likely execute simulations or manage datasets. However, it doesn't name alternative tools, and '取货代码' is a slightly metaphorical term, so not 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when you need specific measurement quantities from an existing dataset without re-running simulation, and explicitly notes that the same dataset can be repeatedly used for different metrics ('不必重跑仿真'). This gives clear when-to-use context, but it doesn't explicitly mention alternative tools or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 BLER anchors are model predictions ('这是模型预测'), gives typical value ranges, and mentions the self-check of the standard table using 'SE == q_m·R/1024'. This provides meaningful context beyond a simple lookup tool, though it doesn't cover edge cases 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, well-structured and front-loaded with the core purpose. Each sentence adds meaningful information, including a caveat and typical ranges. It could be slightly more concise, but it is appropriately sized and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a strong overall context: what the tool does, the nature of the output (standard vs predicted), and typical magnitude expectations. The existence of an output schema covers return values. However, the missing explanation of the `table` parameter is a notable gap for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the `show_bler_anchors` parameter and what it returns (effective SINR and Shannon limit distance). However, it does not explain the `table` parameter at all, leaving its meaning ambiguous. Thus the description adds value for one parameter but not the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the 38.214 MCS/CQI table and BLER model thresholds, which is a specific verb+resource. It distinguishes itself from sibling tools like sw_link_performance or sw_sweep_snr by focusing on standard table lookup rather than simulation or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for manual comparison against public NR link-level curves ('供人工对照公开的 NR 链路级曲线'), but it does not explicitly state when to use this tool vs alternatives, nor does it mention when not to use it. The guidance is mostly implicit.
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 the full burden and lives up to it. It discloses the return behavior (slots sorted by cost, each with 3-4 options), explains what is not included (sample size) and why, and clarifies the underlying logic. This is substantial transparency for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then provides necessary context about the template and sample-size exclusion. It is somewhat long but every sentence contributes value; only minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and the description covers the return behavior well, but the input parameters are under-specified. Given the complexity of the template and the workflow, the missing parameter semantics leaves the tool not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain what answered_design and answered_params mean, their format, or how they map to the slots. The parameter names give a hint, but the agent cannot reliably construct the input without further guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies empty slots in a conclusion template and decides what to ask the user. It defines the template structure with bracketed slots and explains that empty slots become questions, distinguishing it from sibling tools like sw_sample_size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool: to determine what to actively ask the user. It also explicitly says not to ask for sample size and directs to sw_sample_size, offering an alternative. However, it doesn't systematically compare to all sibling tools or provide exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It discloses the default sweep range (-5 to 35 dB), the paired-channel methodology to avoid sampling noise, and provides interpretive guidance for the key output field (efficiency_vs_shannon trend). This is rich behavioral context beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses three short paragraphs, front-loading the core purpose and then adding contextual details. Every sentence contributes value, including the explanation of the paired-channel effect and the output interpretation. It is appropriately sized and well-structured without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and zero schema coverage, the description provides strong purpose, behavioral context, and output interpretation. However, the lack of explanation for most parameters creates a significant gap for correct invocation. The output schema partially compensates for return value understanding, but the parameter gap lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only elaborates on the SNR list semantics by mentioning setting working-point SNRs and the default range. It does not explain dataset_id (the only required parameter), mcs_table, or max_samples. This leaves the agent without meaningful guidance for 3 of the 4 parameters, despite the schema offering only titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sweeps SNR and outputs spectral efficiency/throughput vs SNR curves, including the specific metric types (Shannon, actual, throughput, MCS). It is a specific verb+resource+scope, but it does not explicitly differentiate from sibling tools like sw_throughput or sw_link_performance, so it does not earn 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use: it is described as 'the most standard figure in wireless papers' and explains the benefit of using the same channel batch for paired points. It does not mention when not to use or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 explains that the tool translates credibility checks into gate language, hard failures become blocking items, and users must fix them before proceeding. However, it does not disclose side effects, whether it is read-only, or what output format is expected, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It uses clear formatting to separate the stage explanation and the note about sibling tools. No redundant sentences, though the metaphoric '门禁语言' adds slight ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 2-parameter tool with an output schema, the description provides adequate context: when to use, what it does, and which sibling handles other gates. It doesn't explain prerequisites or dataset_id details, but for a gate tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 clarifies the 'stage' parameter by linking it to Gate 1, but the required 'dataset_id' parameter is not explained at all—its type, source, or relationship to the gate. The description only partially compensates for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a review gate ('评审门') that blocks unsupported conclusions, with a specific verb and resource. It explicitly identifies stage='channel' as Gate 1 and distinguishes Gates 2/3 as belonging to sw_compare_arms, differentiating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage timing: '生成之后、做实验之前跑' (run after generation, before experiments). It also states that Gates 2/3 are in sw_compare_arms, giving a clear alternative and when-not-to-use for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that Chinese city scenes require automatic asset preparation on first use, taking a few seconds. However, it does not clarify whether listing itself triggers this preparation or if it is read-only, and it omits other behavioral details like return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a front-loaded purpose sentence followed by a bullet-like breakdown of scene categories. Every sentence adds value, and there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema, the description covers the main purpose and the key distinction between built-in and auto-prep scenes. It is almost complete, but it could clarify whether calling the list triggers asset preparation and could mention the output shape, even though the schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and there is no schema detail to supplement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists scenes for ray tracing with real building geometry, using the specific verb 'list' and naming the resource 'scenes'. It distinguishes from sibling tools by focusing on scenes, not presets, datasets, or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to know available ray tracing scenes and provides context about built-in vs. auto-prepared city scenes. However, it does not explicitly mention when not to use it or name alternative tools, leaving the guidance implied rather than explicit.
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 the transparency burden. It discloses that each scenario is probed once, lists the returned metrics, mentions per-sample time cost, and references sw_probe_scenario for methodology. It does not explicitly state side-effect status, but the tool is clearly a read/comparison operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with line breaks, a metric list, and a bolded warning. The phrase '每个场景各跑一次探测' is slightly redundant with the first sentence, but the content is mostly purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, typical usage, and output metrics, and an output schema exists for return values. However, with no schema descriptions for the parameters and zero annotation support, the lack of guidance on 'overrides' and 'num_samples' leaves an incomplete picture for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly refers to the 'presets' parameter via '几个场景'. It does not explain 'overrides' or 'num_samples' at all, and the pointer to sw_probe_scenario does not document these parameters. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool probes multiple scenarios side-by-side and returns a comparison table, with a specific use case ('用来在候选场景里选'). It distinguishes itself from the single-scenario sw_probe_scenario and lists concrete output metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it (for selecting among candidate scenarios) and provides a typical workflow, including an explicit negative instruction: do not run ablation on data without verifying interference levels. This is clear when/when-not usage guidance without relying on sibling names.
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?
The description discloses a key behavioral trait: '引擎不可用时不会报错，而是如实标注' (when engines are unavailable, it won't error, but marks them truthfully). This adds value beyond the tool name, and with no annotations available, the description carries the burden well. It does not mention side effects, but for a simple read-only capability check, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core purpose, and the second adds a crucial behavioral note without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple introspection tool with no parameters and an output schema present, the description covers the main purpose and the notable non-error behavior. It doesn't elaborate on output format, but the output schema reduces that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the description adds no parameter-specific semantics. Per the baseline for 0 params, this is a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '查看本机可用的仿真引擎，以及不可用的引擎缺什么' (view available simulation engines and what missing engines lack). The verb '查看' and resource '仿真引擎' are specific, and the tool is distinct among siblings focused on scenarios, datasets, and analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking engine availability, but does not explicitly state when to use it vs alternatives. No exclusions or alternative tools are mentioned, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool does not return a guaranteed configuration and explains that only generation plus verification with sw_interference_report can confirm. It also discloses that some knob effects differ from textbook intuition, adding valuable non-obvious context. It does not explicitly state read-only vs mutating, but for a design-computation tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a bold front-loaded purpose statement followed by two concise sentences covering limitations, dependencies, and additional notes. Every sentence earns its place, with no repetition or filler. The structure guides the reader from 'what' to 'caveats' efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, the non-guarantee limitation, the physical dependencies, and points to the verification tool. Since an output schema exists, return-value details are not needed. For a one-parameter design tool, this is nearly complete; a minor gap is the lack of explicit guidance on parameter values or expected output format, but overall the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (target_iot_db) with 0% description coverage, so the tool description must compensate. The description mentions '干扰强度' (interference strength) and explains IoT depends on geometry/load/power, linking to the parameter's purpose. However, it does not explain the parameter's units, range, or how the numeric value maps to knob settings, leaving the semantic partly to the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear objective: '要构造某个干扰强度的场景，该动哪些旋钮' (which knobs to turn to construct a scenario of a certain interference strength). It also distinguishes itself from the verification sibling by explicitly stating it does not return a guaranteed configuration, making its role as a design-direction tool 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool to get direction and magnitude, then generate a batch and verify with sw_interference_report. The description explicitly mentions that IoT is determined by geometry, load, and power, which sets expectations. It stops short of listing formal when-to-use or when-not-to-use conditions, but the cross-reference to sw_interference_report provides a clear alternative.
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 the burden. It discloses the return content (mean, 95% CI, convergence judgment) and a critical caveat: '不收敛时方案间的差异可能只是噪声' (when not converged, differences may be noise) and that this is explicitly marked. It also explains the behavior of use_estimated_csi (estimated CSI for precoding, ideal CSI for evaluation). This is substantial behavioral disclosure beyond the schema, though it doesn't cover all edge cases like error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary of the pipeline, a context sentence about its role in Monte Carlo simulation, and a focused parameter section with clear bullet points. Each sentence adds value, and the bold warning about convergence is front-loaded. It is appropriately sized for a tool with 5 parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no annotations, no schema descriptions), the description covers the essential aspects: what it computes, the key use case, parameter semantics for the main variables, and the output interpretation (convergence, CI). The output schema exists, so detailed return values need not be described. The main gap is the lack of context for dataset_id and snr_db, but overall the description is sufficient for an AI agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does add meaning for three of five parameters: methods (explains each precoding type and defaults), use_estimated_csi (what true does), and receiver (lists mmse/zf/mrc). However, dataset_id (required) and snr_db are not explained. While these may be self-explanatory from their names, the description misses the required parameter and does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '算谱效：预编码 → 逐层 SINR → 频谱效率' (calculate spectrum efficiency via precoding → per-layer SINR → spectral efficiency) and explicitly mentions horizontal comparison of multiple precoding schemes. This is a specific verb+resource+output, distinguishing it from siblings like sw_throughput or sw_sweep_snr by focusing on link-level precoding comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: '这是蒙特卡洛仿真最常用的评价链路' (the most common evaluation link in Monte Carlo simulations), implying when to use it. It also gives guidance on methods, e.g., '用户自研方案应当和这几个在同一批信道上比' (user-defined schemes should be compared on the same channels), and on use_estimated_csi for CSI feedback topics. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and fully discloses behavior: computes SHA-256, immutable old IDs, tracks metric changes, and marks results as exploratory if inconsistent. This is rich and honest about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and structured, but includes a long philosophical explanation about multiple comparisons. This is informative but could be shortened; still, it remains focused and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and an output schema, the description is not operationally complete. It explains the workflow and integration but leaves all parameter semantics unexplained and does not describe the return value structure beyond prereg_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 9 parameters, and the description does not explain any of them. It mentions 'primary metric' and 'baseline' at a high level but fails to clarify parameters like csi_basis, expected_effect, draft_id, etc. The description should compensate for low schema coverage but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: pre-registering the primary metric and baseline before data generation. It distinguishes itself from siblings by explicitly linking its output (prereg_id) to sw_generate and sw_compare_results, and explains the pre-registration concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before generating data) and describes the workflow: call this tool, get prereg_id, pass to sw_generate, then sw_compare_results judges consistency. It also explains what happens if you change your mind, giving clear usage context.
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 behavior: writes code to a .py file, replaces the my_algorithm function, runs the script, registers two arms, prints result_id, and clarifies that MCP does not execute user code and that per-sample values go to .npz rather than MCP JSON. This is highly 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered steps and bolded key notes. Despite length, every sentence adds value, providing necessary operational details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow, return value (result_id), and file output (.npz), which is good given the output schema exists. However, it omits the roles of dataset_id and metric, leaving a gap in understanding the tool's inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (dataset_id, metric) with 0% description coverage, and the description fails to explain either. Worse, it references a 'code' parameter that is not present in the schema, creating confusion about the actual input contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports an evaluation script skeleton for custom algorithms, explicitly contrasting with sw_compare_arms which only supports six precoding types. It specifies the verb (export), resource (eval script skeleton), and scope (custom algorithms), distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: for custom algorithms not supported by sw_compare_arms. It gives a numbered step-by-step workflow, including how to replace the algorithm, run the script, and hand off result_ids to sw_compare_results, plus a note about MCP not executing user code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that overrides affect simulation parameters, while design does not affect simulation parameters but writes into the plan document. This gives important side-effect context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear intro, code examples, and a clarifying note about design. It is slightly verbose but every sentence adds useful context, and the structure makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and an open-ended overrides object, the description provides enough context to understand the main behavior and side effects. The presence of an output schema means return values don't need to be described. Minor missing details include merge/replace semantics and whether both overrides and design can be provided simultaneously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 does well for overrides and design by providing concrete examples and semantics. However, the required draft_id parameter is only shown in examples and not explicitly explained, leaving a small gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it differentially revises a proposal, requiring only the changes rather than a full restatement. It provides concrete examples of the two main use cases (overrides and design), which distinguishes it from other proposal-related tools like sw_plan or sw_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context with examples: if the user wants to change simulation parameters, use overrides; if the user wants to record design choices, use design. It also implies when not to use this tool (when you don't need to restate the full requirement), but it does not explicitly name alternative tools or exclusion scenarios.
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?
No annotations were provided, so the description carries the full burden. It discloses that BLER is a model, not a measurement, and explicitly lists the three real-world losses (modulation limitation, code rate granularity, finite block length + implementation loss). It also reveals the behavioral nuance that MCS saturation indicates a table limitation rather than channel limitation. This is far more than typical disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: it opens with a clear definition, uses a numbered list for the three losses, and separates output metrics from MCS table guidance. Every sentence earns its place, and the formatting aids readability. It is slightly longer than strictly necessary but appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides rich context about methodology, output metrics, and limitations, and an output schema exists. However, with 5 parameters and zero schema descriptions, key parameters like `method`, `max_samples`, and `target_bler` are left unexplained. This gap means an agent may not know how to set them correctly, making the tool only partially complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 `mcs_table` thoroughly (1 vs 2, 38.214 tables), but says nothing about `method`, `max_samples`, or `target_bler`. These parameters remain ambiguous, and the description does not provide enough detail for an agent to select appropriate values. While `dataset_id` is self-evident, the others need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: '算**真实吞吐**（Mbps）与 3GPP 口径的边缘用户指标' (compute real throughput and 3GPP edge user metrics), and explicitly contrasts with the sibling `sw_link_performance`, which computes the Shannon-bound spectral efficiency. This clearly differentiates the tool's purpose from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool vs. `sw_link_performance`: the latter provides only an unattainable Shannon upper bound, while this tool models real-world losses. It also gives concrete guidance on MCS table selection (if MCS distribution saturates, switch to table 2) and cautions that strict BLER conclusions require a link-level simulator. This directly answers 'when to use' and '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?
No annotations are provided, so the description carries the full burden. It discloses the underlying formula (IoT = 1/(1-load)) and explicitly states that the equivalent load is an interpretive conversion, not a representation of actual scheduling – a valuable caveat. It also warns against mixing input sources, providing behavioral context that a mere schema would not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but well-structured, using a lead sentence followed by three bullet points for the usage modes and a final note on the mathematical relationship. Every sentence adds relevant information, avoiding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with conditional parameter groups and no annotations, the description covers the essential scenarios, formula, and a critical caveat about interpretation. It does not specify behavior when conflicting parameter groups are supplied, but the output schema likely covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate. It explains the role of each parameter: sinr_db+sir_db compute IoT, iot_db is graded and converted to load, and load reverses to IoT. It also notes the requirement for consistent input sources, adding semantic meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair ('IoT 相关的换算与分级') and then enumerates three specific usage modes, distinguishing this conversion utility from sibling tools by its dedicated focus on IoT-related calculations. The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on which parameter groups to supply for each of the three computation modes, including a constraint that sinr_db and sir_db must come from the same geometric SINR calculation. It does not mention alternative tools or when not to use this tool, so it falls short of a full 5.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses the same paired-test/gating implementation as sw_compare_arms, warns that mismatched data can still produce a seemingly significant p-value, and details the blocking conditions. It also describes what the returned statement contains. This is thorough and goes beyond a simple read-only or mutation hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three short paragraphs, front-loading the core purpose. Every sentence adds value: differentiation, validation, warning, and output. It is somewhat verbose but still efficient, and the bolded warnings improve scannability. It earns a 4 rather than 5 because it could be slightly tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate complexity, the description covers the main aspects: purpose, usage differentiation, validation conditions, behavioral edge-case, and output statement. However, it leaves claimed_gain completely unexplained and assumes domain knowledge about gates 2 and 3. The existence of an output schema reduces the need for return-value detail, but the param gap keeps this from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clarifies that result_id_a and result_id_b are two external algorithm results, which adds meaning beyond the raw parameter names. However, the third parameter claimed_gain is never mentioned, leaving its purpose ambiguous. Thus the description only partially explains the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by stating the tool's function: '判决两个外部算法结果' (judge two external algorithm results) and explicitly mentions passing gates 2 and 3. It clearly differentiates itself from the sibling tool sw_compare_arms by noting that while it uses the same statistical implementation, it reads registered results rather than running built-in precoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with sw_compare_arms: '那个现场跑内置预编码，这个读已注册的结果' (that one runs built-in precoding on the spot, this one reads registered results). This tells the agent when to choose this tool over the alternative. It also lists three registration consistency checks that will block execution if not satisfied, providing clear prerequisites.
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 provided, the description carries full burden and does so well: it discloses read-only nature ('只读已落盘的标量'), the formula for IoT, domain separation, and edge-case handling (samples at ±50 dB boundary and sentinel samples counted separately, noted in 'notes'). This substantially exceeds 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-paragraph but well-structured with bold headers and bullet lists. Every sentence adds value: purpose, domain definitions, computation details, and edge cases. It is dense yet efficient, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two domains, a non-trivial formula, and edge cases) and the presence of an output schema, the description covers all necessary points: domain split, link='BOTH' requirement, IoT derivation, and notes behavior. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter with 0% description coverage. The description implicitly indicates that dataset_id identifies the dataset ('一个数据集的干扰画像'), but it does not explicitly define the parameter's format or how to obtain a valid ID. For a single obvious parameter, this is adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '一个数据集的干扰画像：业务域 IoT + 测量域导频 SIR', explicitly stating the tool produces an interference profile for a dataset and identifies the two domains. This specific verb-like scope clearly distinguishes it from sibling tools such as sw_link_performance or sw_iot_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is read-only, and the measurement_domain columns only exist in data generated with link='BOTH', which is a prerequisite. It also warns against an incorrect computation ('不是 snr_dB 减 sinr_dB'), offering guidance. However, it does not explicitly name alternative tools or state when not to use this one.
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 the full burden. It discloses that presets are only skeletons and that group filtering controls output (omitting returns all). It also lists the valid group values. This provides useful behavioral context beyond a simple 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear sentence followed by a structured parameter section. No filler or redundant information. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers the tool's purpose and parameter behavior. It also relates to sw_plan for context. It could mention the output format, but the output schema presumably covers that. Overall, it's sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'group' as an optional string with no description. The description compensates by listing the exact valid group values and explaining the default behavior (all groups when not provided). This fully clarifies the parameter's meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States '列出场景预设' (list scenario presets) with a specific verb and resource. It also clarifies that presets are skeletons, distinguishing them from full scenarios handled by sw_plan. The purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that specific parameters are determined by sw_plan, implying this tool is for exploring preset skeletons rather than building scenarios. It also explains the optional group filter and that omitting it returns all groups. However, it doesn't explicitly enumerate alternative tools or exclusion criteria.
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 provided, the description carries the full disclosure burden. It reveals that the tool does not return data, that auto_decided lists user decisions to relay, that workers may run parallel with different seeds, and quantifies the collect_ssb performance tradeoff. This is far beyond a minimal statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section serves a purpose: usage modes, prereg binding, workers behavior, and collect_ssb tradeoff. It is structured with clear headings and bolded warnings, making it scannable despite the detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers core behavior, performance implications, and user-facing output, and the output schema exists to explain return values. However, it omits descriptions for three parameters (preset, overrides, num_samples) and does not state what happens if neither draft_id nor intent is provided. This leaves minor gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It meaningfully explains draft_id, intent, prereg_id, workers, and collect_ssb, but leaves preset, overrides, and num_samples completely unexplained. It adds significant value for most parameters but is incomplete for the full parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '生成信道数据集，返回句柄与统计摘要（不返回数据本身）', clearly stating the action (generate), the resource (channel dataset), and the return type (handle + stats, not data). This distinguishes it from sibling tools like sw_describe_dataset or sw_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains two usage modes ('协商过：只传 draft_id' and '用户说"随便，默认就行"：直接传 intent'), when prereg_id must be bound ('只能在生成前绑定'), and when to keep collect_ssb enabled ('小区选择、切换、波束管理类课题需要它，别乱关'). This provides clear when-to-use and when-not-to-use guidance.
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?
Despite having no annotations, the description goes beyond basic operation by disclosing that the tool only produces data and does not make judgments, and that it will explain why items are inapplicable (e.g., CDL fixed CDF). It also provides specific 3GPP reference documents, making behavior highly predictable and well-documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then uses a bulleted list to efficiently enumerate outputs with standard clause references. It also adds a clear behavioral caveat about division of labor with sw_gate. Every sentence and bullet adds value; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the methodology, specific outputs with standard references, reference curve sources, what the tool does not do (no judgment), and how it handles inapplicable cases. Given there is also an output schema, the description is complete for an AI agent to select and invoke this tool correctly without needing further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, dataset_id, is not explicitly explained in the description, and schema coverage is 0%. However, the name is self-explanatory and the description implies the tool operates on a dataset by listing calibration outputs for a dataset. The description does not add extra meaning beyond the schema, but the intent is clear enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes calibration quantities per 3GPP TR 38.901 §7.8, which is a specific and unambiguous verb+resource pairing. It also distinguishes itself from siblings by explicitly stating '本工具只出数不判决' (this tool only outputs numbers, not judgments) and pointing to sw_gate for the decision role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions the tool as the standard method for judging whether channel generation is correct, giving clear context for when it is appropriate. It explicitly excludes the judgment step by naming sw_gate as the tool that does that, and also notes that inapplicable cases will be explained, which helps the agent decide when this tool is relevant.
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?
No annotations are provided, so the description carries full disclosure burden. It reveals important behaviors: pairing cancels common channel effects, fairness check blocks config drift and CSI inconsistencies, statistical tests use paired t-test and Wilcoxon signed-rank with specific blocking conditions (95% CI crossing zero, single sample contribution >50%), and it explicitly states when gates are not passed it will state the conclusion is invalid and why. This is rich behavioral context far beyond a typical tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary, then uses a bulleted list to explain the four unique capabilities, and ends with parameter-value notes. Despite being longer than most descriptions, each sentence/bullet adds distinct information (pairing benefits, fairness issues, test details, conclusion behavior). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (paired comparison, multiple gates, statistical tests) and the presence of an output schema, this description is nearly complete. It explains the method's purpose, the gate semantics, the conclusion behavior, and key parameter defaults. The only gaps are minor parameter meanings (receiver, max_samples) and interaction with other tools, but the description stands alone well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage) and no enums. The description compensates by explicitly documenting the allowed values for method_* (svd/svd_wideband/type1/dft/mrt/identity), the meaning of csi_* (ideal vs estimated), and the behavior of snr_db when omitted (uses per-sample SINR). This covers the core comparison parameters. However, it does not explain receiver, max_samples, dataset_id, or name_*, leaving some semantic gaps. Still, the value added for the central parameters is substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement: 'Run two schemes on the same batch of channels, do paired comparison, and pass gates 2 and 3.' It then enumerates four concrete capabilities (pairing, fairness check, statistical tests, conclusion sentence) that distinguish it from ordinary mean-comparison tools and likely from siblings like sw_compare_scenarios. This specific verb+resource+scope makes 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'This is the last gate before drawing conclusions,' providing a clear temporal/decision context. It also implies alternatives by saying it does four things that ordinary 'mean comparison' cannot do, implying use when those advanced features are needed. However, it does not explicitly name sibling tools or give when-not-to-use exclusions, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does well: it discloses the formula, the three behavioral branches, and the pilot behavior of running 20 samples. It does not explicitly state side effects or return format, but since this is a calculation tool and an output schema exists, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a formula, bullet points, and a bolded warning. Every sentence adds value: the formula, three usage modes, the caution about MDE, and the source of std_diff. It is longer than minimal but appropriately detailed for a tool with three distinct operational modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and no annotations, the description covers all needed context: mathematical methodology, all three usage scenarios, the pilot fallback, and a caution about interpreting results. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 all three parameters: std_diff is sourced from sw_compare_arms paired.std_diff, expected_effect is the target effect size for sample size calculation, and n_current is used to compute minimum detectable effect. It also explains the no-arguments case, making parameter semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes required sample size or minimum detectable effect based on statistical parameters, with the opening '算出来的，不是问用户的' and three explicit usage modes. This distinguishes it from sibling tools like sw_plan or sw_compare_arms, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance for all three parameter combinations: with std_diff+expected_effect, with std_diff+n_current, and with none. It also tells users to check the minimum detectable effect first and points to where std_diff comes from (sw_compare_arms paired.std_diff), fully covering usage context.
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?
No annotations are provided, so the description carries the full burden. It discloses internal behavior (num_rb compressed to 24, SSB measurement off), equivalence guarantees (bit-identical geometry for specific RBs), runtime reduction (~1/8), what is returned, and what is not_available. This is exceptionally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a hook, technical details, return info, limitations, and parameter explanations. It is slightly verbose but every section serves a purpose. Front-loaded with the key use case. Not overly wordy for the complexity covered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a probe tool: it explains what it does, what it returns, what it cannot provide, and usage guidance. The presence of an output schema reduces the need to describe return values in detail, and the description covers the non-obvious limitations and safety nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It includes a dedicated '参数' section explaining preset (referencing sw_list_presets), config (as overrides), and num_samples (with guidance on sample sizes for different percentiles). This fully 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "花几十秒看清一个场景长什么样，再决定要不要花几十分钟正式跑" (spend tens of seconds to preview a scenario before committing to a long formal run). It contrasts with the formal generation path and names the resource (scenario), making it distinct from siblings like sw_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use this to decide whether to run a full generation. It also states when not to use it: "这些必须跑正式生成，别拿探测结果替代" (these must run formal generation, don't substitute probe results), giving clear when/when-not boundaries.
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?
Despite having no annotations, the description discloses key behavioral details: the returned questions each include a 'why' explaining how choices affect conclusions, and also_configurable only provides parameter names without expansion. It also instructs to relay the 'why' to the user. This meets the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a concise purpose statement, then a parameter list, then return semantics, and a usage note. Every sentence adds value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, all parameters, return behavior, and even when to use sw_generate instead. Combined with the output schema, the agent has all needed contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all four parameters beyond the schema: intent with an example, preset with auto-selection behavior, overrides as user-specified parameters, and max_questions with a suggested range. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: transforming the user's simulation intent into a configuration proposal and identifying what needs confirmation. It distinguishes itself from the sibling tool sw_generate by noting that if no preferences exist, sw_generate can be called directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises that if the user has no obvious preference, one should call sw_generate directly with defaults, and sw_plan is for when confirmation questions are needed. It also explains that preset can be auto-selected if not provided.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/TianLin0509/SuperRAN'
If you have feedback or need assistance with the MCP directory API, please join our Discord server