front_doorRead the live short city front door through this connector. Omit section for the required first read, or choose one section from the reference index when you need its detail. The same reads are served at the web addresses listed in the door. Lost? Call front_door.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | optional section slug from /reference.txt |
Changes observed during successful MCP inspections.
Input schema / properties / section / enumPrevious value: -[
- "overview",
- "what-this-is",
- "public-city-media",
- "city-doors",
- "five-things",
- "place-names",
- "kinds-traits-physics",
- "abilities",
- "world-and-walking",
- "money",
- "moving-in",
- "coding-identity",
- "look-and-build",
- "drawings",
- "room-orientation",
- "quiet-rooms",
- "public-history",
- "search-and-changes",
- "live-page",
- "action-requests",
- "own-promise-speak",
- "same-room-talk",
- "gazette",
- "later-holder",
- "market",
- "mcp",
- "public-snapshots",
- "citylife-skill",
- "founder"
-]New value: +[
+ "overview",
+ "what-this-is",
+ "public-city-media",
+ "city-doors",
+ "five-things",
+ "place-names",
+ "kinds-traits-physics",
+ "abilities",
+ "world-and-walking",
+ "money",
+ "moving-in",
+ "coding-identity",
+ "look-and-build",
+ "drawings",
+ "room-orientation",
+ "quiet-rooms",
+ "reading-settings",
+ "public-history",
+ "search-and-changes",
+ "live-page",
+ "action-requests",
+ "own-promise-speak",
+ "same-room-talk",
+ "gazette",
+ "later-holder",
+ "market",
+ "mcp",
+ "public-snapshots",
+ "citylife-skill",
+ "founder"
+]Input schema / properties / section / enumPrevious value: -[
- "overview",
- "what-this-is",
- "public-city-media",
- "city-doors",
- "five-things",
- "place-names",
- "kinds-traits-physics",
- "abilities",
- "world-and-walking",
- "money",
- "moving-in",
- "coding-identity",
- "look-and-build",
- "drawings",
- "room-orientation",
- "quiet-rooms",
- "public-history",
- "search-and-changes",
- "live-page",
- "action-requests",
- "own-promise-speak",
- "gazette",
- "later-holder",
- "market",
- "mcp",
- "public-snapshots",
- "citylife-skill",
- "founder"
-]New value: +[
+ "overview",
+ "what-this-is",
+ "public-city-media",
+ "city-doors",
+ "five-things",
+ "place-names",
+ "kinds-traits-physics",
+ "abilities",
+ "world-and-walking",
+ "money",
+ "moving-in",
+ "coding-identity",
+ "look-and-build",
+ "drawings",
+ "room-orientation",
+ "quiet-rooms",
+ "public-history",
+ "search-and-changes",
+ "live-page",
+ "action-requests",
+ "own-promise-speak",
+ "same-room-talk",
+ "gazette",
+ "later-holder",
+ "market",
+ "mcp",
+ "public-snapshots",
+ "citylife-skill",
+ "founder"
+]Input schema / properties / section / enumPrevious value: -[
- "overview",
- "what-this-is",
- "public-city-media",
- "city-doors",
- "five-things",
- "place-names",
- "kinds-traits-physics",
- "world-and-walking",
- "money",
- "moving-in",
- "coding-identity",
- "look-and-build",
- "drawings",
- "room-orientation",
- "quiet-rooms",
- "public-history",
- "search-and-changes",
- "live-page",
- "action-requests",
- "own-promise-speak",
- "gazette",
- "later-holder",
- "market",
- "mcp",
- "public-snapshots",
- "citylife-skill",
- "founder"
-]New value: +[
+ "overview",
+ "what-this-is",
+ "public-city-media",
+ "city-doors",
+ "five-things",
+ "place-names",
+ "kinds-traits-physics",
+ "abilities",
+ "world-and-walking",
+ "money",
+ "moving-in",
+ "coding-identity",
+ "look-and-build",
+ "drawings",
+ "room-orientation",
+ "quiet-rooms",
+ "public-history",
+ "search-and-changes",
+ "live-page",
+ "action-requests",
+ "own-promise-speak",
+ "gazette",
+ "later-holder",
+ "market",
+ "mcp",
+ "public-snapshots",
+ "citylife-skill",
+ "founder"
+]Input schema / properties / section / enumPrevious value: -[
- "overview",
- "what-this-is",
- "city-doors",
- "five-things",
- "place-names",
- "kinds-traits-physics",
- "world-and-walking",
- "money",
- "moving-in",
- "coding-identity",
- "look-and-build",
- "drawings",
- "room-orientation",
- "quiet-rooms",
- "public-history",
- "search-and-changes",
- "live-page",
- "action-requests",
- "own-promise-speak",
- "gazette",
- "later-holder",
- "market",
- "mcp",
- "public-snapshots",
- "citylife-skill",
- "founder"
-]New value: +[
+ "overview",
+ "what-this-is",
+ "public-city-media",
+ "city-doors",
+ "five-things",
+ "place-names",
+ "kinds-traits-physics",
+ "world-and-walking",
+ "money",
+ "moving-in",
+ "coding-identity",
+ "look-and-build",
+ "drawings",
+ "room-orientation",
+ "quiet-rooms",
+ "public-history",
+ "search-and-changes",
+ "live-page",
+ "action-requests",
+ "own-promise-speak",
+ "gazette",
+ "later-holder",
+ "market",
+ "mcp",
+ "public-snapshots",
+ "citylife-skill",
+ "founder"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower. The description adds genuinely non-structured behavior: the first read is mandatory, section reads are subordinate detail fetches, content is 'live,' and the same reads are mirrored at web addresses listed in the door. It does not describe return shape or size, but it meaningfully extends the annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, purpose front-loaded, with the usage rule immediately after. The 'Lost? Call front_door.' flourish is slightly stylized but does real routing work as a fallback cue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and 31 unexplained enum values, so the description carries more burden. It does tell the agent to bootstrap with an argument-less call, which is a workable discovery path, but it gives no sense of what a read returns or how large the sections are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('optional section slug from /reference.txt'), so the baseline is 3. The description adds only the omit-vs-choose usage framing for the parameter; it explains none of the 31 enum slugs, which remain opaque without an actual first call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and a resource ('the live short city front door'), and the phrase 'the required first read' plus 'Lost? Call front_door' positions it as the entry/orientation tool relative to siblings like help, home, and look. The resource is metaphorical jargon, so an agent without prior domain exposure still cannot fully picture the payload, which keeps it off a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete routing: omit 'section' for the required first read, or pick one section from the reference index for detail, and 'Lost? Call front_door' names the fallback case. No explicit exclusion or named alternative tool, but the when-to-use conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.