One Coworking

Search coworking venues

search_venues

Read-only

Use this when the person wants spaces in a city listed on One Coworking. product filters (day_pass, meeting_room, private_office, office_suite, flex_desk, fix_desk, day_office, membership); max_price is EUR in that product's unit (offices: per desk per month, day passes: per day, meeting rooms: per hour). For private_office / office_suite the answer is a broker's shortlist — the well-known brands in the city, then local operators that fit team_size and area; view "list" gives the plain list ranked by fit and price instead. bookable "instant" / "online" keeps venues that book online. Cite the venue pages; get_venue has one venue's details.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>"
    },
    "name": "search_venues"
  }
}

Input Schema

Name	Required	Description
`area`	No	Districts the person wants, e.g. "Kreuzberg or Mitte" — office shortlists prefer spaces there.
`city`	Yes	City name in English, e.g. "Berlin", "Munich", "London".
`near`	No	A station, landmark, hotel or street address in the city to be close to, e.g. "Hauptbahnhof", "Rudi-Dutschke-Straße 5". Ranks spaces by walking minutes from it.
`view`	No	Office searches only: shortlist (default) or the plain ranked list.
`limit`	No
`product`	No
`bookable`	No
`max_price`	No
`team_size`	No	People the office must seat. Ranks offices that fit first; applies with product private_office or office_suite.
`budget_monthly_eur`	No	Total monthly budget for the team, EUR — office shortlists say which options fit it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / near

Added value: +{
+  "description": "A station, landmark, hotel or street address in the city to be close to, e.g. \"Hauptbahnhof\", \"Rudi-Dutschke-Straße 5\". Ranks spaces by walking minutes from it.",
+  "maxLength": 120,
+  "minLength": 2,
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false), and the description adds genuine behavioral context: private_office/office_suite return a broker-style shortlist (well-known brands first, then local operators matching team_size and area) ranked by fit and price, and bookable filters to venues that book online. It stops short of describing pagination or result volume against the limit parameter.

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 usage trigger is front-loaded and the body stays compact given ten parameters, but the run-on structure with parentheticals and inconsistent casing ("product filters", "bookable "instant" / "online"") makes it denser than it needs to be.

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 no output schema, the description carries the burden of describing returns; it does so well for office searches (shortlist composition and ranking) and advises citing venue pages, but says nothing about what a non-office search returns or how limit affects output. Adequate for a read-only search tool with annotation coverage, slightly light for 10 parameters.

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

Parameters4/5

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

Schema coverage is only 60%, and the description compensates with the single most load-bearing detail: max_price is EUR expressed in the selected product's unit (per desk/month for offices, per day for day passes, per hour for meeting rooms). It also explains product, view and bookable semantics. limit and the interaction between max_price and budget_monthly_eur remain explained nowhere.

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+resource+scope: "when the person wants spaces in a city listed on One Coworking." It also distinguishes itself from the nearest sibling by explicitly deferring single-venue lookups to get_venue, so an agent can route correctly without opening either schema.

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 a clear trigger condition (person wants spaces in a city) and names the in-tool alternative (view "list" vs the default shortlist). It does not state when to prefer this over sibling tools such as start_office_brief or request_office_quotes, so the routing guidance is incomplete for a 10-parameter search tool.

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

All One Coworking tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?