Uncategorized

In this tutorial, we build a compact, efficient framework that demonstrates how to convert tool documentation into standardized, callable interfaces, register those tools in a central system, and execute them as part of an automated pipeline. As we move through each stage, we create a simple converter, design mock bioinformatics tools, organize them into a registry, and benchmark both individual and multi-step pipeline executions. Through this process, we explore how structured tool interfaces and automation can streamline and modularize data workflows. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser import re, json, time, random from dataclasses import dataclass from typing import Callable, Dict, Any, List, Tuple @dataclass class ToolSpec: name: str description: str inputs: Dict[str, str] outputs: Dict[str, str] def parse_doc_to_spec(name: str, doc: str) -> ToolSpec: desc = doc.strip().splitlines()[0].strip() if doc.strip() else name arg_block = “n”.join([l for l in doc.splitlines() if “–” in l or “:” in l]) inputs = {} for line in arg_block.splitlines(): m = re.findall(r”(–?w[w-]*|bw+b)s*[:=]?s*(w+)?”, line) for key, typ in m: k = key.lstrip(“-“) if k and k not in inputs and k not in [“Returns”,”Output”,”Outputs”]: inputs[k] = (typ or “str”) if not inputs: inputs = {“in”: “str”} return ToolSpec(name=name, description=desc, inputs=inputs, outputs={“out”:”json”}) We start by defining the structure for our tools and writing a simple parser that converts plain documentation into a standardized tool specification. This helps us automatically extract parameters and outputs from textual descriptions. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser def tool_fastqc(seq_fasta: str, min_len:int=30) -> Dict[str,Any]: seqs = [s for s in re.split(r”>[^n]*n”, seq_fasta)[1:]] lens = [len(re.sub(r”s+”,””,s)) for s in seqs] q30 = sum(l>=min_len for l in lens)/max(1,len(lens)) gc = sum(c in “GCgc” for s in seqs for c in s)/max(1,sum(lens)) return {“n_seqs”:len(lens),”len_mean”:(sum(lens)/max(1,len(lens))),”pct_q30″:q30,”gc”:gc} def tool_bowtie2_like(ref:str, reads:str, mode:str=”end-to-end”) -> Dict[str,Any]: def revcomp(s): t=str.maketrans(“ACGTacgt”,”TGCAtgca”); return s.translate(t)[::-1] reads_list=[r for r in re.split(r”>[^n]*n”, reads)[1:]] ref_seq=””.join(ref.splitlines()[1:]) hits=[] for i,r in enumerate(reads_list): rseq=””.join(r.split()) aligned = (rseq in ref_seq) or (revcomp(rseq) in ref_seq) hits.append({“read_id”:i,”aligned”:bool(aligned),”pos”:ref_seq.find(rseq)}) return {“n”:len(hits),”aligned”:sum(h[“aligned”] for h in hits),”mode”:mode,”hits”:hits} def tool_bcftools_like(ref:str, alt:str, win:int=15) -> Dict[str,Any]: ref_seq=””.join(ref.splitlines()[1:]); alt_seq=””.join(alt.splitlines()[1:]) n=min(len(ref_seq),len(alt_seq)); vars=[] for i in range(n): if ref_seq[i]!=alt_seq[i]: vars.append({“pos”:i,”ref”:ref_seq[i],”alt”:alt_seq[i]}) return {“n_sites”:n,”n_var”:len(vars),”variants”:vars[:win]} FASTQC_DOC = “””FastQC-like quality control for FASTA –seq_fasta: str –min_len: int Outputs: json””” BOWTIE_DOC = “””Bowtie2-like aligner –ref: str –reads: str –mode: str Outputs: json””” BCF_DOC = “””bcftools-like variant caller –ref: str –alt: str –win: int Outputs: json””” We create mock implementations of bioinformatics tools such as FastQC, Bowtie2, and Bcftools. We define their expected inputs and outputs so they can be executed consistently through a unified interface. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser @dataclass class MCPTool: spec: ToolSpec fn: Callable[…, Dict[str,Any]] class MCPServer: def __init__(self): self.tools: Dict[str,MCPTool] = {} def register(self, name:str, doc:str, fn:Callable[…,Dict[str,Any]]): spec = parse_doc_to_spec(name, doc); self.tools[name]=MCPTool(spec, fn) def list_tools(self) -> List[Dict[str,Any]]: return [dict(name=t.spec.name, description=t.spec.description, inputs=t.spec.inputs, outputs=t.spec.outputs) for t in self.tools.values()] def call_tool(self, name:str, args:Dict[str,Any]) -> Dict[str,Any]: if name not in self.tools: raise KeyError(f”tool {name} not found”) spec = self.tools[name].spec kwargs={k:args.get(k) for k in spec.inputs.keys()} return self.tools[name].fn(**kwargs) server=MCPServer() server.register(“fastqc”, FASTQC_DOC, tool_fastqc) server.register(“bowtie2”, BOWTIE_DOC, tool_bowtie2_like) server.register(“bcftools”, BCF_DOC, tool_bcftools_like) Task = Tuple[str, Dict[str,Any]] PIPELINES = { “rnaseq_qc_align_call”:[ (“fastqc”, {“seq_fasta”:”{reads}”, “min_len”:30}), (“bowtie2”, {“ref”:”{ref}”, “reads”:”{reads}”, “mode”:”end-to-end”}), (“bcftools”, {“ref”:”{ref}”, “alt”:”{alt}”, “win”:15}), ] } def compile_pipeline(nl_request:str) -> List[Task]: key = “rnaseq_qc_align_call” if re.search(r”rna|qc|align|variant|call”, nl_request, re.I) else “rnaseq_qc_align_call” return PIPELINES[key] We build a lightweight server that registers tools, lists their specifications, and allows us to call them programmatically. We also define a basic pipeline structure that outlines the sequence in which tools should run. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser def mk_fasta(header:str, seq:str)->str: return f”>{header}n{seq}n” random.seed(0) REF_SEQ=””.join(random.choice(“ACGT”) for _ in range(300)) REF = mk_fasta(“ref”,REF_SEQ) READS = mk_fasta(“r1”, REF_SEQ[50:130]) + mk_fasta(“r2”,”ACGT”*15) + mk_fasta(“r3”, REF_SEQ[180:240]) ALT = mk_fasta(“alt”, REF_SEQ[:150] + “T” + REF_SEQ[151:]) def run_pipeline(nl:str, ctx:Dict[str,str]) -> Dict[str,Any]: plan=compile_pipeline(nl); results=[]; t0=time.time() for name, arg_tpl in plan: args={k:(v.format(**ctx) if isinstance(v,str) else v) for k,v in arg_tpl.items()} out=server.call_tool(name, args) results.append({“tool”:name,”args”:args,”output”:out}) return {“request”:nl,”elapsed_s”:round(time.time()-t0,4),”results”:results} We prepare small synthetic FASTA data for testing and implement a function that runs the entire pipeline. Here, we dynamically pass tool parameters and execute each step in the sequence. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser def bench_individual() -> List[Dict[str,Any]]: cases=[ (“fastqc”, {“seq_fasta”:READS,”min_len”:25}), (“bowtie2”, {“ref”:REF,”reads”:READS,”mode”:”end-to-end”}), (“bcftools”, {“ref”:REF,”alt”:ALT,”win”:10}), ] rows=[] for name,args in cases: t0=time.time(); ok=True; err=None; out=None try: out=server.call_tool(name,args) except Exception as e: ok=False; err=str(e) rows.append({“tool”:name,”ok”:ok,”ms”:int((time.time()-t0)*1000),”out_keys”:list(out.keys()) if ok else [],”err”:err}) return rows def bench_pipeline() -> Dict[str,Any]: t0=time.time() res=run_pipeline(“Run RNA-seq QC, align, and variant call.”, {“ref”:REF,”reads”:READS,”alt”:ALT}) ok = all(step[“output”] for step in res[“results”]) return {“pipeline”:”rnaseq_qc_align_call”,”ok”:ok,”ms”:int((time.time()-t0)*1000),”n_steps”:len(res[“results”])} print(“== TOOLS ==”); print(json.dumps(server.list_tools(), indent=2)) print(“n== INDIVIDUAL BENCH ==”); print(json.dumps(bench_individual(), indent=2)) print(“n== PIPELINE BENCH ==”); print(json.dumps(bench_pipeline(), indent=2)) print(“n== PIPELINE RUN ==”); print(json.dumps(run_pipeline(“Run RNA-seq QC, align, and variant call.”, {“ref”:REF,”reads”:READS,”alt”:ALT}), indent=2)) We benchmark both individual tools and the full pipeline, capturing their outputs and performance metrics. Finally, we print the results to verify that each stage of the workflow runs successfully and integrates smoothly. In conclusion, we develop a clear understanding of how lightweight tool conversion, registration, and orchestration can work together in a single environment. We observe how a unified interface allows us to connect multiple tools seamlessly, run them in sequence, and measure their performance. This hands-on exercise helps us appreciate how simple design principles, standardization, automation, and modularity can enhance the reproducibility and efficiency of computational workflows in any domain. Check out the FULL CODES here. Feel free to check out our GitHub Page for Tutorials, Codes and Notebooks. Also, feel free to follow us on Twitter and don’t forget to join our 100k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post A Coding Implementation to Build a Unified Tool Orchestration Framework from Documentation to Automated Pipelines appeared first on MarkTechPost.

arXiv:2510.13939v1 Announce Type: new Abstract: The use of copyrighted books for training AI models has led to numerous lawsuits from authors concerned about AI’s ability to generate derivative content.Yet it’s unclear whether these models can generate high quality literary text while emulating authors’ styles. To answer this we conducted a preregistered study comparing MFA-trained expert writers with three frontier AI models: ChatGPT, Claude & Gemini in writing up to 450 word excerpts emulating 50 award-winning authors’ diverse styles. In blind pairwise evaluations by 159 representative expert & lay readers, AI-generated text from in-context prompting was strongly disfavored by experts for both stylistic fidelity (OR=0.16, p

arXiv:2510.13908v1 Announce Type: new Abstract: Large Language Models (LLMs) have demonstrated impressive reasoning capabilities but continue to struggle with arithmetic tasks. Prior works largely focus on outputs or prompting strategies, leaving the open question of the internal structure through which models do arithmetic computation. In this work, we investigate whether LLMs encode operator precedence in their internal representations via the open-source instruction-tuned LLaMA 3.2-3B model. We constructed a dataset of arithmetic expressions with three operands and two operators, varying the order and placement of parentheses. Using this dataset, we trace whether intermediate results appear in the residual stream of the instruction-tuned LLaMA 3.2-3B model. We apply interpretability techniques such as logit lens, linear classification probes, and UMAP geometric visualization. Our results show that intermediate computations are present in the residual stream, particularly after MLP blocks. We also find that the model linearly encodes precedence in each operator’s embeddings post attention layer. We introduce partial embedding swap, a technique that modifies operator precedence by exchanging high-impact embedding dimensions between operators.

arXiv:2509.06917v2 Announce Type: replace-cross Abstract: We introduce Paper2Agent, an automated framework that converts research papers into AI agents. Paper2Agent transforms research output from passive artifacts into active systems that can accelerate downstream use, adoption, and discovery. Conventional research papers require readers to invest substantial effort to understand and adapt a paper’s code, data, and methods to their own work, creating barriers to dissemination and reuse. Paper2Agent addresses this challenge by automatically converting a paper into an AI agent that acts as a knowledgeable research assistant. It systematically analyzes the paper and the associated codebase using multiple agents to construct a Model Context Protocol (MCP) server, then iteratively generates and runs tests to refine and robustify the resulting MCP. These paper MCPs can then be flexibly connected to a chat agent (e.g. Claude Code) to carry out complex scientific queries through natural language while invoking tools and workflows from the original paper. We demonstrate Paper2Agent’s effectiveness in creating reliable and capable paper agents through in-depth case studies. Paper2Agent created an agent that leverages AlphaGenome to interpret genomic variants and agents based on ScanPy and TISSUE to carry out single-cell and spatial transcriptomics analyses. We validate that these paper agents can reproduce the original paper’s results and can correctly carry out novel user queries. Paper2Agent automatically created AI co-scientist that identified new splicing variant associated with ADHD risk. By turning static papers into dynamic, interactive AI agents, Paper2Agent introduces a new paradigm for knowledge dissemination and a foundation for the collaborative ecosystem of AI co-scientists.

arXiv:2506.02132v4 Announce Type: replace Abstract: Large transformer-based language models dominate modern NLP, yet our understanding of how they encode linguistic information relies primarily on studies of early models like BERT and GPT-2. Building on classic BERTology work, we analyze 25 models spanning from classical architectures (BERT, DeBERTa, GPT-2) to modern large language models (Pythia, OLMo-2, Gemma-2, Qwen2.5, Llama-3.1), probing layer-by-layer representations across eight linguistic tasks in English. Consistent with earlier findings, we find that hierarchical organization persists in modern models: early layers capture syntax, middle layers handle semantics and entity-level information, and later layers encode discourse phenomena. We dive deeper, conducting an in-depth multilingual analysis of two specific linguistic properties – lexical identity and inflectional morphology – that help disentangle form from meaning. We find that lexical information concentrates linearly in early layers but becomes increasingly nonlinear deeper in the network, while inflectional information remains linearly accessible throughout all layers. Additional analyses of attention mechanisms, steering vectors, and pretraining checkpoints reveal where this information resides within layers, how it can be functionally manipulated, and how representations evolve during pretraining. Taken together, our findings suggest that, even with substantial advances in LLM technologies, transformer models learn to organize linguistic information in similar ways, regardless of model architecture, size, or training regime, indicating that these properties are important for next token prediction. Our code is available at https://github.com/ml5885/model_internal_sleuthing

arXiv:2510.13909v1 Announce Type: new Abstract: Inductive Knowledge Graph Reasoning (KGR) aims to discover facts in open-domain KGs containing unknown entities and relations, which poses a challenge for KGR models in comprehending uncertain KG components. Existing studies have proposed Knowledge Graph Foundation Models (KGFMs) that learn structural invariances across KGs to handle this uncertainty. Recently, Large Language Models (LLMs) have demonstrated strong capabilities for open-domain knowledge reasoning. As a result, the latest research has focused on LLM-based KGFMs that integrate LLM knowledge with KG context for inductive KGR. However, the intrinsic knowledge of LLMs may be overshadowed by sparse KG context, leading to LLM knowledge distortion, which can cause irreversible damage to model reasoning. Moreover, existing LLM-based KGR methods still struggle to fully constrain generative hallucinations in LLMs, severely limiting the credibility of reasoning results. To address these limitations, we propose a Knowledge Reasoning Language Model (KRLM) that achieves unified coordination between LLM knowledge and KG context throughout the KGR process. Specifically, we design a Knowledge Reasoning Language (KRL) instruction format and a KRL tokenizer to align LLM knowledge with KG representations. Then, we propose a KRL attention layer that coordinates intrinsic LLM knowledge with additional KG context through a dynamic knowledge memory mechanism. Finally, a structure-aware next-entity predictor is proposed, which strictly constrains the reasoning results within a trustworthy knowledge domain. Extensive experimental results on 25 real-world inductive KGR datasets demonstrate the significant superiority of the proposed KRLMfootnote{Our source codes are available at https://anonymous.4open.science/r/KRLM-EA36 in both zero-shot reasoning and fine-tuning scenarios.

arXiv:2510.13163v1 Announce Type: new Abstract: Most large language models (LLMs) today excel at generating raw, sequential code with minimal abstractions and custom structures. However, there has been little work on graph-based abstract code generation, where significant logic is encapsulated in predefined nodes and execution flow is determined by edges. This is relevant for visual programming languages, and in cases where raw source code is inaccessible to users and LLM training sets. In this work, we propose and evaluate JSON representations for graphs to enable high accuracy graph-based abstract code generation. We evaluate these representations on ScratchTest, a mini-benchmark based on our custom Python re-implementation of Scratch, which tests the LLM in code graph space. Our findings demonstrate that LLMs can indeed perform the aforementioned generation task in a single pass without relying on specialized or complex pipelines, given the correct graph representations. We also show that different representations induce significantly different accuracies, highlighting the instrumental role of representations in this generation task. All in all, this work establishes the first steps towards representation learning for graph-based abstract code generation.