MCP + LLMs = our solution to data integration problems, which include context awareness limitations.

It's an exciting development and I am glad you see it too!

It's really frustrating. I've come to loathe the agreeable tone because every time i see it i remember the times where i've hit this pain point in design.

    Not chatty.  Unbiased.  Avoid use of emoji.  Rather than "Let me know if..." style continuations, list a set of prompts to explore further topics.  Do not start out with short sentences or smalltalk that does not meaningfully advance the response.

As an aside, I like the further prompt exploration approach.

An example of this from the other day - https://chatgpt.com/share/68767972-91a8-8011-b4b3-72d6545cc5... and https://chatgpt.com/share/6877cbe9-907c-8011-91c2-baa7d06ab4...

One part of this in comparison with the linked in post is that I try to avoid delegating choices or judgement to it in the first place. It is an information source and reference librarian (that needs to be double checked - I like that it links its sources now).

However, that's a me thing - something that I do (or avoid doing) with how I interact with an LLM. As noted with the stories of people following the advice of an LLM, it isn't something that is universal.

    Answer concisely when appropriate, more 
    extensively when necessary.  Avoid rhetorical 
    flourishes, bonhomie, and (above all) cliches.  
    Take a forward-thinking view. OK to be mildly 
    positive and encouraging but NEVER sycophantic 
    or cloying.  Above all, NEVER use the phrase 
    "You're absolutely right."

What’s new here isn’t just exposing `current_datetime()`. The server also gives the model tools to reason about time:

  (1) time_difference(t1, t2)  – exact gaps with human wording  

  (2) timestamp_context(t)      – “weekend evening”, “workday morning”  

  (3) time_since(t)             – “2 h ago, earlier today”  

Ask Claude “what patterns do you see so far?” after a few exchanges.

If you still find it trivial after trying, happy to hear why—genuinely looking for ways to push this further. Thanks for the candid feedback.

Finding a good title is really hard. I'd appreciate any advice on that. You'll notice I wrote the article several weeks ago, and that's how long it took me to figure out how to pitch on HN. I'd appreciate any feedback to improve. Thanks!

(Submitted title was "Show HN: I gave Claude a sundial and it built a calendar")

`uv` is great but `pipenv` is a perfectly well-tested Python dependency manager (albeit slow). Down in the instructions it explicitly asks you to use `pipenv` to manage* dependencies. I also do not think your assertion of "what is a Pipfile in any context" is fair, as I don't think I've ever seen a project list a dependency manager and then explicitly call out artifacts that the dependency manager may require to function.

My only worry with these MCP "sensors" is that they add-up to the token cost — and more importantly to the context window cost. It would be great to have the models regularly poll as new data and factor that into their inferences. But I think the models (at least with current attention) will always have a trade-off between how much they are provided and what they can focus on. I am afraid that if I provide Claude numerous senses, that it will lower its attention to our conversation.

But your exciting comment (and again I apologize for disappointing you!) makes me think about creating an MCP server that provides like the position of the sun in the sky for the current location, or maybe some vectorized representation of a specific sundial.

I think the digitized information that we experience is more native to models (i.e., require fewer processing steps to extract insights from), but it's possible that providing them this kind of input would result in unexpected insights. They may notice patterns, i.e., more grumpy when the sun is in this phase, etc.

Thanks for your thoughtfulness!