rf-agent

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct stage (spec, analytic model, candidate layout, solve, optimize, export) and the descriptions explicitly differentiate the high-level rf_design from rf_optimize and rf_doctor from rf_altium_preflight. Minor overlap exists between rf_line_model and rf_synthesize's analytic seed, and between the two environment-check tools, but the descriptions are clear enough to avoid serious misselection.
Naming Consistency4/5
All tools share the rf_ prefix and snake_case verb_noun style (list_devices, make_spec, export_altium), making the surface easy to scan. A few names are noun-heavy or verbless — rf_doctor, rf_line_model, rf_job_status, rf_design — which slightly breaks the otherwise consistent pattern.
Tool Count5/5
Twelve tools is well-scoped for an RF design-and-optimization workflow: preflight checks, spec creation, modeling, synthesis, solving, optimization, job tracking, and Altium export each have a dedicated entry point. No tool feels redundant, and the count is manageable.
Completeness5/5
The surface covers the full design loop: health checks, device discovery, spec capture, analytic modeling, candidate generation, full-fidelity solving, optimization, asynchronous job status, and Altium export with a dry-run safety path. There are no obvious dead ends or missing lifecycle steps for the stated RF synthesis and export purpose.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that the tool returns a list, that it is read-only, or any other behavior. The agent is left completely in the dark about what happens when called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It omits essential information (e.g., that it lists something) and what it does say is vague and potentially misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the tool returns. A simple tool with zero parameters could be fully described in one clear sentence, but this is incomplete and leaves the agent uncertain about the tool's purpose and result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already fully covered. The description adds nothing about parameters, but there is nothing to add. The baseline of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('The parametric structures...') rather than a verb phrase indicating an action. It does not state that this tool lists devices/structures, making its purpose ambiguous. It also fails to distinguish itself from sibling tools like rf_list_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or when to use an alternative. The description provides no context about the typical use case, and no sibling comparison is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state that the tool returns progress and result when done, which is a basic behavioral trait, but it omits any information about whether the operation is read-only, whether it blocks, errors on unknown job_ids, or any authentication/rate-limit requirements. The information is minimal and insufficient for safe autonomous use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler, and the core purpose is front-loaded. However, it lacks structured elaboration, such as bullet points or clarifications, which might have improved clarity without adding fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which need not be duplicated in the description), the description fails to provide essential context: it doesn't mention that job_id likely originates from launching a design or optimization job, or that this tool complements rf_list_jobs. The description is too sparse to fully enable an agent to know when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation about the parameters job_id or include_result. It doesn't clarify the meaning of include_result (e.g., what result is, or the impact of setting it to false) or how job_id should be obtained. The tool relies entirely on parameter names, which is inadequate for 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides progress and result information for a running study or design loop, which distinguishes it from sibling tools like rf_design or rf_optimize that launch processes, and rf_list_jobs that likely list jobs. However, the phrase 'study or design loop' is somewhat vague and doesn't explicitly name any sibling or contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as rf_list_jobs or rf_design. There is no mention of polling patterns, prerequisites (e.g., needing a job_id from a prior call), or when this is the appropriate choice over other status-related tools. Usage context is entirely implied.
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 behavioral disclosure. It communicates that the tool enumerates all jobs run in the current session, which is useful, but it does not mention whether the operation is read-only, whether results include failed jobs, or any other behavioral nuance. The listing behavior itself is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, short sentence that states the tool's scope without any filler. It is appropriately sized for a zero-parameter listing tool and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple zero-parameter list operation, especially with an output schema available. However, it lacks any connection to sibling tools or usage context, so an agent may not know when to choose this over rf_job_status without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 and the description does not need to explain parameter meanings. The description adds no parameter information, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (jobs) and scope (this server, this session), and the name 'rf_list_jobs' reinforces the listing action. It is understandable and distinct from sibling tools like rf_job_status, though it lacks an explicit verb and does not directly contrast itself with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies a historical/session-scoped listing use case, but it does not mention rf_job_status or any other sibling, nor does it state when not to use the 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 behavioral disclosure burden. It honestly reveals the no-solving behavior, the analytic-seed behavior when params is null, the low cost profile, and the PNG output. It does not clarify side effects such as whether out_dir writes files or how render affects output, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely tight and front-loaded: the core behavior appears in the first sentence, usage guidance follows immediately, and the final sentence points at the inspectable output. Every line adds information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are not required. Still, with no annotations and a required spec parameter that has zero schema explanation, the description is not fully self-sufficient. It captures purpose and cost well but leaves parameter semantics and the distinction from rf_design under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the null-params case and hints at a PNG. It does not explain what the required spec should be, nor what render or out_dir control. Three of four parameters remain effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Draw') and object ('candidate layout') and adds a critical behavioral constraint ('without solving it'), which differentiates it from the solver siblings. However, it does not explicitly distinguish itself from rf_design, which may also be a layout-generation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: it is cheap and meant for sanity-checking dimensions, DRC, and board size before committing solver time. This implies a before-solve workflow, but it names no alternatives and does not state explicit when-not-to-use conditions.
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, and it does well: it discloses the three distinct failure modes (eda-agent not importable, Altium not running, bridge script not started) and states that the tool reports how to fix the missing piece. This gives an agent a clear model of what the tool examines and what it returns without overpromising. It does not explicitly state that the tool is read-only or whether it performs fixes itself, but the diagnostic framing makes that reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences with zero filler. The key question is front-loaded, followed by a list of the three checks and the fix behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with an output schema, the description is largely complete: it covers what is checked and what is reported. It could be strengthened by explicitly stating when to run it (e.g., 'run before rf_export_altium') or confirming non-destructiveness, but these are minor gaps given the preflight naming and the question format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. Nothing in the description needs to explain parameter meanings, and the description instead clarifies what the tool checks internally. No parameter documentation gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's core function as a preflight check: determining whether a live Altium session is reachable with a PCB open and ready to write. It names the three conditions verified, which adds specificity beyond the tool name. However, the purpose is phrased as a question rather than an explicit verb+resource statement, and it does not directly distinguish itself from rf_export_altium or rf_design siblings by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name 'preflight' and the description imply this should be used before operations that require a live Altium session (e.g., export), but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternative tools or state conditions that would route an agent elsewhere. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that limit values mean 'at or below' and that requirement_text is retained for traceability in the report. However, it does not clarify whether the spec is returned, saved via save_to, or validated, leaving some side-effect behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry real signal: purpose, limit convention, and traceability. No filler; the distinguishing fact that every downstream tool reads this spec is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema reduces the need to describe return values, and the most subtle parameter semantics are covered. Gaps remain around side effects (save_to behavior), the meaning of several un-described parameters, and explicit when-not-to-use guidance, so the definition is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains the meaning of s11_db and isolation_db as negative-dB max limits, and it explains requirement_text's role in the report. Most of the other 12 parameters, such as n_way, bandwidth_frac, excess_loss_db, and save_to, still lack descriptive semantics beyond their titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Turn') and identifies both the input ('requirement') and output ('structured spec'). 'Everything else reads' clearly positions this tool upstream of siblings like rf_design, rf_synthesize, and rf_solve, so an agent can distinguish it without opening any other tool definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the context: when you have a requirement and need the canonical spec that all downstream tools consume. The pipeline positioning is clear, though it does not explicitly name when-not-to-use alternatives or list exclusion cases.
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 present, the description carries the behavioral burden. It discloses that the call is blocking, that full-fidelity is slower, that draft is coarser, and that results are cached by geometry content. This is good beyond the schema but does not cover return values or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose, perfomance expectation, draft toggle, and caching are each stated directly. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core workflow, timing, and the draft option, but leaves the 'params' argument unexplained and does not describe what the score result looks like. An agent could probably invoke it, but may not know what to pass in params or how to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for spec, draft, or params. The description clarifies that spec is the candidate being solved and that draft toggles fast mode, but params is never explained. With low schema coverage, the description compensates only partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Solve one candidate in HFSS and score it against the spec.' This clearly distinguishes it from sibling tools like rf_synthesize or rf_optimize by focusing on solving/scoring a single candidate, not generating or optimizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for using the tool: it is blocking, full-fidelity takes minutes, and draft=True provides a faster coarser answer. It also notes caching behavior. It does not explicitly compare with alternative siblings or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so richly: it is asynchronous, the winner is re-solved at full fidelity, Altium grid snapping is handled, and write_altium mutates an open PCB and requires a live eda-agent bridge. These are exactly the non-obvious behaviors an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the tool's purpose, and every sentence earns its place by explaining async behavior, fidelity guarantees, or side-effect prerequisites. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no schema descriptions and no annotations, the description covers the workflow and side effects well, but it omits crucial invocation details for the required spec parameter and most optional parameters. The output schema covers return value shape, so the main remaining gap is parameter-level guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all six parameters, but it only meaningfully explains write_altium and the Altium-grid behavior. spec is required and opaque, and out_dir, n_trials, timeout_s, and altium_origin_mils are not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run the whole closed loop: seed, optimise, verify, export, report.' This clearly distinguishes the end-to-end tool from siblings like rf_optimize, rf_synthesize, and rf_export_altium.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that this is the whole closed loop, implying use of individual siblings for narrower steps, and explicitly directs the agent to poll rf_job_status and to check rf_doctor before using write_altium. It does not exhaustively enumerate when-not-to-use conditions, but the workflow guidance is clear.
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 the full behavioral burden and does so thoroughly. It discloses that non-dry runs touch the board, that the output is design intent rather than raw EM polygons, and the integer-mil rounding/impedance risk. This goes well 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful paragraphs with the main action first, the output model second, and the critical dry-run warning third. Every sentence earns its place and the formatting improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core workflow is well covered and an output schema exists for return values, so that burden is reduced. However, with six parameters and 0% schema coverage, several important inputs — especially the free-form spec and params — are not explained. It is adequate but has clear 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverae is 0%, so the description must compensate for the six parameters. It only really explains dry_run — its default, effect, and purpose. spec, params, place_pour, place_vias, and origin_mils are left undocumented, leaving significant ambiguity about how an agent should populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact action — 'Write a design into the PCB document the user currently has open' — and specifies the output form: centrelines as tracks, ground vias as vias, coplanar ground as polygon pour, explicitly distinguishing it from EM-polygon exports. The verb, resource, and style are all clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires an open PCB document and directs the agent to use dry_run first and review the quantisation report before committing. It does not explicitly compare against sibling tools like rf_altium_preflight or state when not to use it, so it misses the top tier.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It honestly reveals that this is a closed-form approximation and explicitly warns that it is not accurate enough to finalize a design. This gives an agent useful expectations about fidelity and its role in the larger pipeline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-ordered, and free of filler. It leads with the main outputs, then explains the two invocation modes, and ends with an important accuracy caveat. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers core invocation modes and accuracy context. Minor gaps remain around what happens when both width_mm and z0 are supplied or neither is supplied, and valid laminate values are not explained, but the description is broadly sufficient for an agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains the central width_mm/z0 analysis-vs-synthesis relationship, but it does not describe f0_ghz, gap_mm, or laminate beyond what their names and defaults imply. The parameter names are fairly self-explanatory, but the description leaves some semantic burden on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's domain (Grounded-CPW impedance, effective permittivity, wavelength) and its two operation modes: analyse with width_mm and synthesise with z0. It distinguishes itself from sibling tools by explicitly framing it as the closed-form model the optimizer seeds from, not a full solver or optimizer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when it should be used: it is accurate enough to start from but not accurate enough to finish on, which implies it is for initial estimates rather than final design. It also tells users when to provide width_mm versus z0. However, it does not explicitly name sibling alternatives or state when to prefer them.
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 behavioral burden. It discloses the action ('Check', 'Reports') and lists the three check categories, but it does not state whether the tool modifies anything, makes network calls, or has runtime implications. Acceptable for a zero-parameter diagnostic, but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: the first states purpose, the second names the concrete output areas, and the third gives the usage rule. Every sentence earns its place with no padding or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument diagnostic with an output schema, the description fully tells an agent what the tool checks and when to call it. There are no hidden inputs or required clarifications, and the output schema can handle the exact return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully defines the invocation surface. The description adds task-level context about what will be checked, but no parameter-level detail is needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and resource ('the RF toolchain on this machine'), then enumerates the concrete checks: AEDT install, Python packages, and Altium bridge reachability. This clearly distinguishes it from the design, solve, and export siblings as a pre-flight diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit timing guidance: 'Call this first when anything behaves oddly.' It lacks an explicit when-not-to-use or named alternatives, but the toolchain-wide diagnostic scope makes the intended use unmistakable.
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 does so well by explaining that the call returns a job id immediately, that trial 0 is always the analytic seed, that exploration runs at draft mesh, and that results are not verified/exported/reported unless rf_design is used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then async behavior, then the caveat and alternative. Every sentence earns its place, and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is operationally complete for an asynchronous optimization tool: it tells the agent what happens, what to do next, and which sibling to use for verified results. Minor gaps remain around configuring `spec` and what prerequisites exist, but the sibling tools and self-explanatory parameters fill most of those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It adds meaning to `spec` by referencing 'device's parameters' and clarifies the study's trial behavior, though it doesn't explicitly explain `seed`, `n_trials`, or `timeout_s`. The parameter names and defaults are largely self-explanatory, making this a solid but not exhaustive contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Start an Optuna study over the device's parameters, scored by HFSS.' It distinguishes itself from rf_design by explicitly saying to call rf_design instead when the winner should be verified, exported, and reported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly tells the agent when this tool is appropriate: for exploration at draft mesh. It names the alternative, rf_design, and the condition for choosing it, while also directing the caller to poll rf_job_status after getting a job id.
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:

[![rf-agent MCP server](https://glama.ai/mcp/servers/tisn1678065900-dot/rf-agent/badges/card.svg)](https://glama.ai/mcp/servers/tisn1678065900-dot/rf-agent)

Score Badge

Copy to your README.md:

[![rf-agent MCP server](https://glama.ai/mcp/servers/tisn1678065900-dot/rf-agent/badges/score.svg)](https://glama.ai/mcp/servers/tisn1678065900-dot/rf-agent)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tisn1678065900-dot/rf-agent'

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