-
Notifications
You must be signed in to change notification settings - Fork 9
Description
As a replacment or alternative for set-wiki. The latter might still be useful in some scenarios, hence this task is about adding the optional argument, rather than also about removal of set-wiki. We can figure out separately if that one is still useful.
Pseudo code example
Allow for
getPage( 'foo.example.com', 'Main Page' )
getPage( 'bar.example.com', 'Main Page' )
instead of
setWiki( 'foo.example.com' )
getPage( 'Main Page' )
setWiki( 'bar.example.com' )
getPage( 'Main Page' )
Why this works
The optional URL argument should work smoothly, because the users initial prompt could be something like "I have my test wiki at test.example.wiki and production at www.example.wiki", so if they say something like "copy the pages from the Foo category on my test wiki to production" later, the LLM should be able to provide the correct arguments for all the calls, without extra work for the user
Considering Use Cases
-
All users must use one wiki: for instance internal corporate wiki. User should not be able to switch wiki or need to specify anything about the wiki to use. Perhaps the wiki is set via MCP config by the system admins, or perhaps they stuff the information into the LLM context in another way. Either way,
set-wikiis not needed, and the optional arguments to change wiki should be ignored. -
Multiple wikis: a "general wiki helper chatbot". The wikis to use are not known in advance. Argument is needed. See "Why this works" example
-
One add-hoc wiki: similar to last one. Slightly better served by having
set-wiki, but unclear this justifies the added complexity. Also unclear how common and distinct of a use case this is. A chat about a single wiki might become a multi wiki chat later.