ksri
Joined 15 years ago
Joined 15 years ago
Some examples: - Table of contents can't be updated via the API. But the tool will ensure that the ToC doesn't disappear - Styling can't be represented in markdown. That's fine - new content in the same paragraph will inherit the styles. The tool won't change the styles.
The core approach - don't mess with anything that isn't represented in markdown.
The way it works: we take the original google document and only apply the specific changes that the author intended to make. So this ensures we don't change anything else.
We opened chrome, navigated the entire website, the downloaded the network tab as an har file. The asked claude to analyze and document the apis as an openapi json. Worked amazing.
Next step - we wrote a small python script. On one side, this script implements stdio mcp. On the other side, it calls the Internal apis exposed by the 3rd party app. Only thing missing is the auth headers..
This is the best part. When claude connects to the mcp, the mcp launches a playwright controlled browser and opens the target web apication. It detects if the user is logged in. Then it extracts the auth credentials using playwright, saves them to a local cache file and closes the browser. Then it accesses the apis directly - no browser needed thereafter.
In about an hour worth of tokens with claude, we get a mcp server that works locally with each users credentials in a fairly reliable manner. We have been able to get this working in otherwise locked down corporate environments.
Lots of effort has gone into testing against real world docs. Its beta quality right now.
The hypothesis is that llms are better off getting the "big picture" by reading local files. They can then spend tokens to edit the document as per the business needs rather than spending tokens to figure out how to edit the document.
Another aspect is the security model. Extrasuite assigns a permission-less service account per employee. The agent gets this service account to make API calls. This means the agent only gets access to documents explicitly shared with it, and any changes it makes show up in version history separate from the user's changes.
Early release can be found over here - https://github.com/think41/extrasuite.
re. what happens if its a big book - each "tab" in the google doc is a folder with its own document.xml. A top-level index.xml captures the table of contents across tabs. The agent reads index.xml and then decides what else to read. I am now improving this by giving it xpath expressions so it can directly pick the specific sections of interest.
Philosophically, we wanted "declarative" instead of "imperative". Our key design - the agent needs to "think" in terms of the business, and not worry about how to edit the document. We move all the reconcilliation logic in the library, and free the agent from worrying about the google doc. Same approach in other libraries as well.
It provides a git like pull/push workflow to edit sheets/docs/slides. `pull` converts the google file into a local folder with agent friendly files. For example, a google sheet becomes a folder with a .tsv, a formula.json and so on. The agent simply edits these files and `push`es the changes. Similarly, a google doc becomes an XML file that is pure content. The agent edits it and calls push - the tool figures out the right batchUpdate API calls to bring the document in sync.
None of the existing tools allow you to edit documents. Invoking batchUpdate directly is error prone and token inefficient. Extrasuite solves these issues.
In addition, Extrasuite also uses a unique service token that is 1:1 mapped to the user. This means that edits show up as "Alice's agent" in google drive version history. This is secure - agents can only access the specific files or folders you explicitly share with the agent.
This is still very much alpha - but we have been using this internally for our 100 member team. Google sheets, docs, forms and app scripts work great - all using the same pull/push metaphor. Google slides needs some work.
Another thing I do is ask for the claude session log file. The inputs and thought they provided to claude give me a lot more insight than the output of claude. Quite often I am able to correct the thought process when I know how they are thinking. I've found junior developers treat claude like a sms - small ambiguous messages with very little context, hoping it would perform magic. By reviewing the claude session file, I try to fix this superficial prompting behaviour.
And third, I've realized claude works best of the code itself is structured well and has tests, tools to debug and documentation. So I spend more time on tooling so that claude can use these tools to investigate issues, write tests and iterate faster.
Still a far way to go, but this seems promising right now.
In short, with 1 GET API call that uses 3 SQL queries, you are getting a list of questions, related answers and related comments.
You should parse that example as follows - 1. The first SQL query fetches all the questions, filtered by API parameters 2. The second SQL query fetches all comments for the questions selected in the first query. See the `WHERE c.postid in {{ questions.id | inclause }}` part - questions.id is coming from the output of the first query 3. The output of the first and second query is merged together on the basis of the questionid that is present in both the query output. 4. Similar approach is used for all the answers
The core problem is that google docs' only provides a single API called batchUpdate. This is really painful to use - because the underlying model uses indexes - and it is very painful to keep track of indexes as you update the google docs.
Tools like gws and gogcli technically support batchUpdate. But because the underyling API is so painful - the agent / LLM cannot do anything more than basic updates.
My team uses google docs extensively. And these documents have their own life. Team members leave comments / feedback. Others perhaps apply formatting. Different people contribute to the document - that is the whole point of using google docs. In such a scenario, the agent must be able to play along well - it cannot mess up the document for others.
To solve these problems, I have been working on a CLI tool - ExtraSuite. See https://github.com/think41/extrasuite
The core workflow is just two commands:
`extrasuite docs pull <url> <folder>` downloads the google docs and saves it as markdown files, one per tab in the google doc. It also saves a `comments.xml` - so that the agent can address your comments / feedback.
The agent then edits the markdown files. No special instructions - it knows how to edit markdown files. These can be simple edits, complex rewrites, adding new files, creating tables, adding images or anything that github flavoured markdown allows.
`extrasuite docs push <folder>` - then figures out what the agent changed by comparing locally. This is markdown to markdown diff. Then it figures out how to appy those exact changes to google docs and ultimately reconciles the google doc to match the markdown
ExtraSuite makes a few guarantees:
- It won't mess up formatting, images, headers/footers, styles, colours etc. They will continue to work properly - In general, anything that cannot be represented in markdown won't be touched in the write process.
ExtraSuite has several other features: - Leave comments in the document and ask your agent to work on them. - Full support for tables, images, code blocks, and github flavoured markdown.
If you have either of gws or gogcli installed, you can directly start using extrasuite without any setup.
Our teams have been using this for several months now, and happy to answer any questions about it. Would love your feedback!