Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Open the dashboard in the browser

freeapply_open_dashboard
Read-onlyIdempotent

Open the local FreeApply dashboard in your browser to accept Terms, fill settings, answer pending questions, or review applications and replies when user action is needed.

Instructions

Opens the user's local FreeApply dashboard in their browser, on one tab. Unlike freeapply_status, which only reports its address, it puts the page in front of the user. Use it when the user has to act there: accept the Terms, fill in settings, answer questions waiting on them, or review applications and replies. Not for reading data; the other tools give you the same information. Behavior: changes no data. Starts the dashboard if needed, on http://127.0.0.1:7878 or the next free port; only this computer can reach it. Parameters: tab picks the page: overview (the Terms show there until accepted), settings (the setup fields), issues (the Needs you list of questions and sign-ups), applications or replies. Default overview. Returns: {url, opened}. url null: the dashboard couldn't start (no free port); tell the user. opened false with a url: no browser could be launched; give the user the url.

Input Schema

NameRequiredDescriptionDefault
tabNoThe page to open. Optional; default overview.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / tab / description
      Previous value: -"Tab to show. Optional; default overview."New value: +"The page to open. Optional; default overview."
  2. Changed2 schema fields changedv1.0.1
    • addedInput schema / properties / tab / description
      Added value: +"Tab to show. Optional; default overview."
    • addedInput schema / properties / tab / enum
      Added value: +[
+  "overview",
+  "applications",
+  "replies",
+  "issues",
+  "settings"
+]
  3. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior. The description adds useful context beyond that: it starts the dashboard if needed, uses localhost on port 7878 or the next free port, is reachable only from this computer, and changes no data.

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

Conciseness5/5

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

The description is front-loaded with the action and the sibling distinction, then cleanly sections usage, behavior, parameters, and returns. Despite its length, every section carries operational value for correct invocation.

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?

There is no output schema, but the description explains the {url, opened} return shape and both failure modes: null url when the dashboard cannot start, and false opened with a url when no browser could be launched. That is enough for an agent to act correctly.

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

Parameters5/5

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

The schema documents the tab parameter and enum values, but the description adds meaningful semantics for each tab: overview shows Terms until accepted, settings shows setup fields, issues shows the Needs list, and applications/replies are review tabs. This materially improves selection beyond the raw enum names.

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

Purpose5/5

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

States a specific verb and resource: opening the user's local FreeApply dashboard in their browser. It explicitly distinguishes itself from freeapply_status, which only reports the address, so the agent can choose between them without inspecting schemas.

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?

Gives explicit when-to-use guidance: when the user must accept Terms, fill settings, answer waiting questions, or review applications and replies. It also gives a clear when-not-to-use rule: not for reading data because other tools provide the same information.

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

Deploy Server

Other Tools