How do I use flru-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flru-mcp find relevant projects for a Python developer" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

flru-mcp

by creator137

Overview Schema Source Related Servers Discussions Admin

Python

Local

marketplace-mcp

Local MCP server for working with marketplace and freelance platforms. The current implementation supports FL.ru, Avito, and Freelancer.com: Codex or another MCP client can browse projects, inspect details, score relevance, keep local history, save proposal/bid drafts, and preview submission in dry-run mode.

The server is intentionally not an autonomous proposal bot. Sending proposals is a separate tool and defaults to dry-run.

Requirements

Python 3.12+
uv
Chromium for Playwright
FL.ru account for authenticated features
Freelancer.com account for authenticated bid features

Related MCP server: kwork-mcp

Installation

uv sync --extra dev
uv run playwright install chromium

Copy .env.example to .env and fill only local secrets there:

cp .env.example .env

Important defaults:

FLRU_DRY_RUN=true
FLRU_BROWSER_PROFILE=./data/browser-profile
FLRU_STORAGE_STATE=./data/storage_state.json
FLRU_DATABASE=./data/flru_mcp.sqlite3
FLRU_EXPERTISE_PROFILE=./config/expertise.yml

Avito defaults:

AVITO_DRY_RUN=true
AVITO_BROWSER_PROFILE=./data/avito-browser-profile
AVITO_STORAGE_STATE=./data/avito_storage_state.json
AVITO_CLIENT_ID= and AVITO_CLIENT_SECRET= are optional, but required for official API calls.

Freelancer.com defaults:

FREELANCER_DRY_RUN=true
FREELANCER_BROWSER_PROFILE=./data/freelancer-browser-profile
FREELANCER_STORAGE_STATE=./data/freelancer_storage_state.json
FREELANCER_LOGIN= and FREELANCER_PASSWORD= are optional, but allow Playwright to prefill login.

First Authentication

FL.ru login currently shows Yandex SmartCaptcha. The server does not bypass it.

Run the MCP tool flru_login from a client, or run the server and call the tool with:

{ "headless": false }

Playwright opens FL.ru login. Complete login and any CAPTCHA/2FA manually. The resulting browser storage state is saved under data/.

Freelancer.com authentication works the same way through freelancer_login. The server can prefill credentials from .env, but captcha, email confirmation, 2FA, billing/profile prompts, and other checks must be completed manually.

Launch MCP Server

uv run marketplace-mcp

Codex MCP configuration example:

{
  "mcpServers": {
    "flru": {
      "command": "uv",
      "args": ["run", "marketplace-mcp"],
      "cwd": "/home/stepanov-sv/projects/marketplace-mcp",
      "env": {
        "FLRU_DRY_RUN": "true"
      }
    }
  }
}

Tools

FL.ru:

flru_auth_status
flru_login
flru_list_projects
flru_search_projects
flru_get_project
flru_find_relevant_projects
flru_mark_project_seen
flru_get_unseen_projects
flru_get_project_history
flru_get_proposal_context
flru_save_proposal_draft
flru_get_proposal_draft
flru_submit_proposal
flru_get_customer
flru_list_conversations
flru_get_conversation
flru_send_message

Avito:

avito_auth_status
avito_login
avito_list_my_ads
avito_get_ad
avito_create_ad_draft
avito_get_ad_draft
avito_list_ad_drafts
avito_open_create_ad_page
avito_publish_ad

Freelancer.com:

freelancer_auth_status
freelancer_login
freelancer_list_projects
freelancer_search_projects
freelancer_get_project
freelancer_find_relevant_projects
freelancer_get_bid_context
freelancer_save_bid_draft
freelancer_get_bid_draft
freelancer_submit_bid

Message tools currently return NOT_IMPLEMENTED until authenticated message endpoints are verified.

Avito Workflow

Avito support uses the official API where possible and Playwright only for manual browser sessions.

To use API-backed tools, create Avito API credentials in the Avito account/API settings and set:

AVITO_CLIENT_ID=...
AVITO_CLIENT_SECRET=...

Then:

1. avito_auth_status
2. avito_list_my_ads
3. avito_create_ad_draft
4. avito_publish_ad

avito_publish_ad returns a dry-run preview while AVITO_DRY_RUN=true.

Real automated publication is not enabled yet because Avito returned IP/CAPTCHA protection during research and the authenticated add-item form was not safely verified. Use avito_open_create_ad_page to open the human page for manual inspection/completion. The server must not bypass CAPTCHA, IP checks, paid placement, moderation, or other manual verification.

Freelancer.com Workflow

Freelancer.com public project discovery uses HTTP and server-rendered job pages. Authentication and bid-related checks use Playwright because the login and bid UI are dynamic and can require manual verification.

Typical dry-run flow:

1. freelancer_list_projects or freelancer_find_relevant_projects
2. freelancer_get_project for selected candidates
3. freelancer_get_bid_context
4. Client drafts a tailored bid
5. freelancer_save_bid_draft
6. freelancer_submit_bid returns a preview because FREELANCER_DRY_RUN=true

Real bid submission is intentionally disabled until the authenticated bid form is verified with fixtures and success checks. With FREELANCER_DRY_RUN=false, freelancer_submit_bid still checks authentication, project state, and local duplicates, then returns REAL_FREELANCER_BID_SUBMISSION_NOT_VERIFIED.

Dry-Run Workflow

1. flru_find_relevant_projects
2. flru_get_project for selected candidates
3. Client drafts a proposal from source data
4. flru_save_proposal_draft
5. flru_submit_proposal returns a preview because FLRU_DRY_RUN=true

No FL.ru modification is made in dry-run.

Real Submission Workflow

Real submission is intentionally not enabled yet because the authenticated freelancer proposal form was not verified during public-page research. With FLRU_DRY_RUN=false, flru_submit_proposal still performs auth, project, duplicate, closed-project, and form checks, then returns REAL_SUBMISSION_NOT_ENABLED_FOR_UNVERIFIED_FORM unless a verified proposal form is parsed.

Before enabling real submission, inspect the authenticated form with Playwright, document fields in docs/flru-research.md, add fixtures/tests, and verify success from the project page after submit. Never retry ambiguous POSTs automatically.

Debugging

Set:

FLRU_HEADLESS=false
FLRU_DEBUG=true

Browser failure screenshots and HTML snapshots are stored under data/debug/.

Local Scanner

uv run flru-scan

The scanner discovers and scores projects into SQLite. It never submits proposals.

Tests

uv run pytest

Current tests cover parsers, budgets, project detail extraction, relevance scoring, SQLite history/drafts, dry-run submission, and duplicate prevention.

Known FL.ru Limitations

Public project pages are server-rendered and parseable over HTTP.
Login includes SmartCaptcha, so authentication is manual through Playwright.
FL.ru uses DDoS-Guard; crawling is sequential with respectful delays.
Authenticated proposal and message forms were not verified from public research, so real sending is disabled.
CSS selectors are isolated in parser functions and documented in docs/flru-research.md.

Known Freelancer.com Limitations

Public project lists are parseable over HTTP from /jobs/ and skill pages such as /jobs/php/.
Login is an Angular/SPA flow, so Playwright is used for authentication.
Captcha, 2FA, email checks, profile completion, and paid/billing prompts are never bypassed.
Real bid submission is not enabled until the authenticated form is documented in docs/freelancer-research.md and covered by tests.

Available Tools

17 tools

flru_auth_statusA

Checks whether the current FL.ru session is authenticated.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It conveys that the tool is a read-only status check with no side effects, but it does not specify return values, error behavior, or whether it makes a network call. This is adequate for a simple check but leaves out some details one might expect.

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

Conciseness5/5

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

The description is a single sentence of eight words, with no filler or repetition. It front-loads the essential information and 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/5

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

Given the tool's simplicity (no parameters, no output schema), the description is largely complete: it states what is checked. However, it could be more explicit about the return type (e.g., a boolean) or any preconditions, but these are strongly implied by the wording. Sibling tool context further clarifies its role.

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 description does not need to explain parameter meanings. Baseline for 0 parameters is 4; the description correctly focuses on the tool's purpose rather than on nonexistent inputs.

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

Purpose5/5

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

The description clearly states the tool checks whether the current FL.ru session is authenticated, using the specific verb 'checks' and resource 'session authentication.' This distinguishes it from sibling tools like flru_login, which performs authentication, and other tools that act on projects or conversations.

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

Usage Guidelines3/5

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

The description gives no explicit guidance on when to use this tool versus alternatives. However, the purpose itself implies usage context: to verify authentication before other operations. It lacks any mention of alternatives or prerequisites, so it offers only implied usage.

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

flru_find_relevant_projectsD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`max_pages`	No
`min_score`	No
`only_unseen`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_conversationD

ParametersJSON Schema

Name	Required	Description	Default
`conversation_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_customerD

ParametersJSON Schema

Name	Required	Description	Default
`profile_url`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_projectD

ParametersJSON Schema

Name	Required	Description	Default
`url`	No
`project_id`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_project_historyD

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_proposal_contextD

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_proposal_draftD

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_get_unseen_projectsD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_list_conversationsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_list_projectsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`query`	No
`category`	No
`only_new`	No
`budget_max`	No
`budget_min`	No
`subcategory`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_loginB

Starts a manual Playwright login session and persists browser storage state.

ParametersJSON Schema

Name	Required	Description	Default
`headless`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description discloses key behaviors: it's manual (interactive) and persists browser storage state. However, it doesn't detail the flow, such as whether it blocks until login, how errors are handled, or where the state is stored, leaving gaps for an agent.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that conveys both action and side effect without padding or redundancy.

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

Completeness3/5

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

The tool is simple (one optional boolean param, no output schema), but the description omits context about the overall authentication flow, such as when to run it relative to other tools and what constitutes successful completion. Enough for basic understanding but not fully complete.

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

Parameters2/5

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

Schema description coverage is 0% and the description never mentions the 'headless' parameter. The boolean parameter is left unexplained, forcing the agent to infer its meaning from the parameter name alone.

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

Purpose5/5

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

Description clearly states it starts a manual Playwright login session and persists browser storage state, with a specific verb and resource. It distinguishes itself from sibling tools like flru_auth_status by indicating it initiates a login rather than checking status.

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 vs alternatives like flru_auth_status. It does not mention prerequisites (e.g., needing to run before other 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.

flru_mark_project_seenD

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_save_proposal_draftD

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`project_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_search_projectsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`query`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_send_messageD

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`conversation_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

flru_submit_proposalD

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`price`	No
`project_id`	Yes
`delivery_days`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

17 tool updatesv0.1.0Aug 11, 2026
- First observedflru_auth_status
- First observedflru_find_relevant_projects
- First observedflru_get_conversation
- First observedflru_get_customer
- First observedflru_get_project
- First observedflru_get_project_history
- First observedflru_get_proposal_context
- First observedflru_get_proposal_draft
- First observedflru_get_unseen_projects
- First observedflru_list_conversations
- First observedflru_list_projects
- First observedflru_login
- First observedflru_mark_project_seen
- First observedflru_save_proposal_draft
- First observedflru_search_projects
- First observedflru_send_message
- First observedflru_submit_proposal

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2/5.0

Scored 2026-08-11 15:20 across 17 tools

Disambiguation4/5

Tools are mostly distinct, each targeting a specific resource (projects, proposals, conversations, customer, auth). However, the project-related tools (find_relevant_projects, get_unseen_projects, list_projects, search_projects) may overlap in purpose, especially without detailed descriptions.

Naming Consistency4/5

Names generally follow a consistent flru_verb_noun pattern (e.g., flru_get_project, flru_send_message). A few exceptions like flru_login and flru_auth_status deviate slightly, but the overall pattern is predictable and readable.

Tool Count3/5

With 17 tools, this sits in the 16-25 range that feels heavy. The count is justified by the broad scope (auth, projects, proposals, conversations, customer), but some tools may be redundant (multiple project discovery variants), making the set slightly larger than necessary.

Completeness4/5

The tool surface covers the core workflow from authentication through project discovery, proposal drafting/submission, and client communication. Missing operations like updating/withdrawing proposals or marking conversations read, but the main lifecycle is well represented.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113399
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
RU Books MCP
io.github.books-service
MCP server for Russian books search, details, and recommendation candidates.
Search Art & Culture Entertainment & Media
2
nü people Job Server A
io.github.nu-people
Public MCP server for discovering open jobs. Search, filter, and get application links.
Search
52

Related MCP Servers

Freelo MCP Server
Project Management Workplace & Productivity
karlost
A
license
Not graded
quality
B
maintenance
MCP server for Freelo project management API, enabling task and project management through natural language.
Updated 2 months ago (2026-07-21 11:43 UTC)
19 npm
10
MIT
kwork-mcp
E-commerce & Retail Communication Project Management
simonether
A
license
A
quality
B
maintenance
MCP server that exposes 25 tools for the Kwork freelance marketplace — browse projects, submit offers, manage orders, send messages, and more.
Updated 2 months ago (2026-07-28 11:21 UTC)
28
3
MIT
1c-buddy-mcp
Developer Tools Code Analysis AI & Machine Learning
VVi3ard
A
license
B
quality
C
maintenance
Lightweight MCP server for 1C.ai integration, enabling queries, code analysis, and documentation search via natural language.
Updated 3 months ago (2026-06-19 12:46 UTC)
8
2
AGPL 3.0
upwork-mcp
Project Management Communication CRM
greerso
F
license
Not graded
quality
F
maintenance
MCP server for the Upwork GraphQL API enabling job search, contract management, proposal drafting, and other Upwork automation tasks via natural language.
Updated 2 months ago (2026-07-01 22:49 UTC)
-